Invalidação de cache no desenvolvimento móvel: estratégias e mecanismos

O que é invalidação de cache?

Invalidação de cache é o processo de invalidar ou atualizar entradas em cache que não correspondem mais ao estado atual da fonte de dados. Ao contrário de limpar manualmente todo o cache, a invalidação funciona seletivamente: apenas os dados cuja relevância está em questão.

O cache armazena cópias de dados para acesso rápido. Com o tempo, os dados originais no banco de dados ou no servidor podem mudar — por exemplo, um usuário atualizou seu perfil ou uma nova postagem apareceu no feed. Se o cache não for invalidado, o aplicativo mostrará informações desatualizadas, o que em aplicativos móveis leva a erros de transação, exibição incorreta e perda de confiança.

A principal dificuldade de qualquer invalidação é o conhecido ditado “There are only two hard things in Computer Science: cache invalidation and naming things”. A complexidade reside no fato de que o cache não sabe quando a fonte mudou, a menos que seja explicitamente notificado.

De acordo com Martin Kleppmann, autor de “Designing Data-Intensive Applications” (O'Reilly, 2017), a invalidação correta requer notificação centralizada de alterações ou um mecanismo para verificar a relevância a cada leitura — um compromisso entre desempenho e consistência.

data class CacheEntryT(
    val data: T,
    val expiresAt: Long,
    val version: Int = 0
)

fun CacheT.isValid(key: String): Boolean =
    get(key)?.let { it.expiresAt > currentTimeMillis() && it.version == currentVersion(key) } ?: false

Este código mostra uma abordagem simples: uma entrada em cache é considerada válida se o TTL não expirou e a versão corresponde à atual na fonte. O mecanismo de versionamento é uma das maneiras confiáveis de evitar exibir dados desatualizados.

Por que a invalidação é necessária em aplicativos móveis

Atualidade dos dados é um requisito chave para a maioria dos aplicativos móveis: redes sociais, mensageiros, serviços bancários, plataformas de e-commerce. Um usuário que vê um saldo de conta incorreto ou mensagens antigas perde a confiança no aplicativo.

Além da experiência do usuário, a invalidação economiza tráfego e bateria. Em vez de recarregar periodicamente todos os dados, um aplicativo móvel pode invalidar apenas as entradas alteradas e carregá-las seletivamente. De acordo com a Meta Engineering (2024), a implementação de invalidação incremental no Facebook Lite reduziu o consumo de tráfego em 35% sem perder a atualidade do conteúdo.

Outro aspecto importante é a consistência das transações. Em aplicativos com carrinho de compras ou sistema de reservas, o uso de cache obsoleto pode levar a cobranças duplicadas ou conflitos de dados. A invalidação após operações críticas garante que a próxima solicitação leia dados frescos.

Principais estratégias de invalidação de cache

TTL (Time-To-Live)

TTL é a estratégia mais simples, onde cada entrada em cache recebe um tempo de vida fixo. Quando o TTL expira, os dados são considerados obsoletos e removidos na próxima leitura. TTL é ideal para dados atualizados em um cronograma — por exemplo, clima ou taxas de câmbio. Desvantagem: os dados podem estar desatualizados dentro do intervalo TTL.

Write-Through

Com a estratégia Write-Through, cada alteração de dados passa pelo cache: a gravação é realizada simultaneamente no cache e na fonte. Isso garante que o cache sempre contenha a versão atual. A desvantagem é o aumento da latência de gravação, pois a operação não é concluída até que a fonte confirme. Write-Through é adequado para dados críticos para consistência: saldo de conta, status do pedido.

Write-Behind (Write-Back)

Write-Behind é uma gravação assíncrona: os dados vão imediatamente para o cache e são gravados na fonte posteriormente por um processo separado. Isso proporciona alto desempenho de gravação, mas acarreta risco de perda de dados em caso de falha antes da sincronização. Em aplicativos móveis, Write-Behind é frequentemente usado para análises, logs e ações de usuário não críticas.

Write-Invalidate

Write-Invalidate — em vez de atualizar o cache quando os dados mudam, ele simplesmente remove (invalida) a entrada correspondente. A próxima leitura detectará uma falha de cache e carregará dados frescos da fonte. Esta estratégia é simples de implementar e funciona bem quando as solicitações de leitura superam significativamente as de gravação.

A escolha da estratégia depende do que é mais importante para um cenário específico: velocidade de resposta, consistência ou economia de recursos. Abordagens híbridas — por exemplo, TTL com Write-Invalidate ao receber uma notificação push — fornecem um equilíbrio ideal.

Como a invalidação funciona em diferentes níveis de cache

Cache HTTP é o primeiro nível no lado do cliente. O navegador ou aplicativo móvel armazena as respostas do servidor com cabeçalhos Cache-Control e ETag. A invalidação ocorre ao receber uma resposta 304 Not Modified ou quando max-age expira. ETag permite que o cliente verifique a atualidade do recurso sem baixar a resposta completa.

Cache do aplicativo é o segundo nível, gerenciado por código: caches em memória (LRU, LruCache no Android) ou em disco (SQLite, Room, Realm). A invalidação aqui é controlada pelo desenvolvedor. De acordo com Android Developers (2025), o uso correto do Room com Flow e invalidação baseada em gatilhos reduz as redesenhos da UI em 40%.

Cache do servidor é o terceiro nível: Redis, Memcached, CDN. Neste nível, a invalidação é feita através de TTL, comandos DEL/PURGE ou brokers de mensagens (RabbitMQ, Kafka). A invalidação de CDN é um desafio separado: devido à natureza distribuída da CDN, um comando de purga pode levar minutos para se propagar globalmente. De acordo com a Cloudflare (2024), a invalidação via Purge by URL leva em média 5–15 segundos para propagação global.

Para coordenar a invalidação em todos os níveis, utiliza-se um serviço de cache centralizado ou um broker de eventos. Quando os dados mudam, a fonte publica um evento, e cada nível recebe um comando para invalidar chaves específicas. Isso evita uma situação em que um nível já atualizou os dados enquanto outro continua servindo a versão obsoleta.

Erros comuns na invalidação de cache

TTL muito longo é o erro mais comum. Os desenvolvedores definem TTL com margem, fazendo com que os usuários vejam dados desatualizados por horas ou dias. Solução: comece com um TTL curto (1–5 minutos) e aumente somente após medir a necessidade real.

Invalidar todo o cache em uma única alteração é um problema típico na arquitetura de microsserviços. Um usuário atualiza seu avatar e o cache é invalidado para todos. Com um grande número de usuários, isso causa um Cache Stampede — uma avalanche de solicitações à fonte. Solução: invalidar apenas a chave do usuário específico, não o cache compartilhado.

Falta de invalidação em erros de gravação — se a gravação na fonte falhar mas o cache já foi atualizado, o aplicativo fica em um estado inconsistente. Solução: invalidação em duas fases — primeiro limpar o cache, depois gravar na fonte e reverter a invalidação em caso de erro.

Ignorar a natureza distribuída — em um ambiente clusterizado, a invalidação em um nó não significa que outros nós receberam o comando. Sem um broker de eventos, alguns servidores continuarão servindo dados obsoletos. Redis Pub/Sub ou Apache Kafka resolvem esse problema transmitindo eventos de invalidação.

Como escolher uma estratégia de invalidação

Determine os requisitos de atualidade — quão crítico é que os dados estejam atualizados “agora mesmo.” Para um feed de notícias, um atraso de 1–2 minutos é aceitável (TTL). Para o saldo de uma conta, o atraso é inaceitável (Write-Through).

Avalie a frequência de alterações — dados que são atualizados uma vez por dia (catálogo de produtos, guia de cidades) funcionam bem com TTL. Dados que mudam dezenas de vezes por segundo (status online, taxas de câmbio) exigem invalidação push via WebSockets ou Firebase Cloud Messaging.

Considere o custo de leitura da fonte — se a fonte é uma consulta SQL cara em 10 tabelas ou uma API externa com limites, use cache agressivo com TTL longo, mas compense dados obsoletos com invalidação push. Se a leitura é barata (consulta em memória), use TTL curto e Write-Invalidate.

De acordo com o Google I/O (2025), o padrão típico para aplicativos móveis é Stale-While-Revalidate: o usuário vê instantaneamente os dados em cache enquanto o aplicativo verifica sua atualidade em segundo plano e os atualiza. Isso combina velocidade de resposta e atualidade sem compromissos. O cabeçalho HTTP Cache-Control com a diretiva stale-while-revalidate é suportado a partir do Android 10 e iOS 13.