Cache Invalidation Estrategias: 7 Metodos para Dados Consistentes

Manter dados consistentes entre cache e fonte original e um dos problemas mais antigos da computação. A pergunta que orienta toda decisão aqui é simples: quando o dado original muda, quanto tempo o cache pode continuar servindo a versão antiga sem causar prejuízo? A resposta varia conforme o cenário, e é por isso que existem estrategias diferentes de cache invalidation. Abaixo, apresentamos sete abordagens, da mais simples à mais sofisticada, com criterios concretos para você decidir qual adotar.

1. TTL (Time-to-Live) e Expiração

A estrategia mais direta consiste em definir um tempo de vida para cada entrada do cache. Após esse período, o dado é considerado expirado e a próxima leitura busca a versão atualizada na fonte original. O TTL funciona bem quando a tolerância a dados levemente desatualizados é aceitável. Por exemplo, uma lista de produtos com preços que mudam no máximo uma vez por dia pode usar TTL de 24 horas sem problema. O criterio para escolher o TTL é o SLA de frescor: se o negócio aceita atraso de X minutos, o TTL deve ser igual ou menor que X. O desafio é calibrar o valor: TTL curto demais reduz o benefício do cache, TTL longo demais serve dados velhos.

2. Write-Through Cache

Nesta abordagem, toda escrita vai primeiro para o cache e depois para o banco de dados, de forma sincrona. O cache nunca fica desatualizado porque a atualização acontece na mesma operação da escrita. O custo é maior latência na escrita, mas a leitura é sempre consistente. Write-through é ideal para sistemas onde leitura é muito mais frequente que escrita e onde consistencia imediata é critica. Um exemplo prático é um sistema de inventario: cada venda atualiza o cache e o banco juntos, então a proxima consulta de estoque já reflete a mudança. A ressalva: se o cache falhar, a escrita precisa ser direcionada ao banco para não perder dados.

3. Write-Back Cache

Ao contrario do write-through, o write-back atualiza apenas o cache na hora da escrita e persiste no banco de forma assincrona, em lotes. Isso reduz drasticamente a latência de escrita, mas aumenta o risco de perda de dados se o cache cair antes da persistencia. Write-back é comum em sistemas de alta taxa de escrita, como logs de acesso ou contadores de visualização, onde uma perda pequena é aceitavel. O criterio de uso é: quanto dado você pode perder em uma janela de X segundos? Se a resposta for zero, não use write-back. Se for aceitavel perder alguns registros, o ganho de performance compensa.

4. Write-Around Cache

Nesta estrategia, as escritas vão direto ao banco, sem passar pelo cache. Apenas as leituras de dados que não estão no cache são carregadas para ele. Isso evita poluir o cache com dados que podem nunca ser lidos. Write-around é util quando a taxa de escrita é alta e a taxa de re-leitura do mesmo dado é baixa. Um exemplo: um sistema de arquivos onde arquivos são gravados uma vez e raramente acessados novamente. O cache só guarda o que é realmente lido, economizando espaço e mantendo a consistencia simples: o cache nunca tem dado sujo porque ele só contém o que veio de leituras. A desvantagem é que a primeira leitura após uma escrita é lenta, pois precisa buscar no banco.

5. Cache-Aside (Lazy Loading)

Tambem conhecido como lazy loading, o cache-aside coloca a responsabilidade no aplicativo: ele verifica o cache primeiro, se não encontrar, busca no banco e popula o cache. A invalidation é feita manualmente ou via TTL. Essa estrategia é flexivel e facil de implementar, mas exige disciplina para garantir que a invalidation aconteça após cada escrita. Um erro comum é esquecer de invalidar após uma atualização, resultando em dados velhos servidos indefinidamente. O criterio para usar cache-aside é ter controle sobre o ciclo de vida dos dados e uma equipe que entenda os fluxos de escrita. Em sistemas com muitas rotas de escrita, o risco de esquecimento aumenta.

6. Invalidação por Evento (Event-Driven Invalidation)

Em vez de esperar o TTL expirar, a invalidation é disparada por eventos: quando uma escrita acontece no banco, um evento é emitido e o cache é atualizado ou removido para aquele dado especifico. Isso garante consistencia quase imediata sem sacrificar a performance de leitura. Essa abordagem exige uma infraestrutura de mensageria, como Kafka ou RabbitMQ, e um consumidor que processe os eventos. É ideal para sistemas distribuidos com multiplos serviços compartilhando o mesmo cache. O desafio é lidar com eventos fora de ordem ou duplicados, que podem causar atualizações incorretas. O criterio de escolha: se você ja tem uma fila de eventos no sistema, essa estrategia adiciona pouco custo e elimina o problema do TTL.

7. Versionamento de Dados (Versioned Cache)

A estrategia mais robusta envolve versionar cada entrada do cache. Em vez de invalidar, você grava uma nova versão do dado com um identificador unico. As leituras sempre buscam a versão mais recente, e versões antigas são descartadas por um processo de limpeza. Isso elimina a corrida entre escrita e leitura: mesmo que uma leitura comece antes da escrita terminar, ela nunca recebe uma versão parcial. Versionamento é usado em sistemas de configuracao distribuida, como etcd ou Consul, onde a consistencia é critica. O custo é maior complexidade e uso de memoria, pois versões antigas permanecem até serem coletadas. Para a maioria dos casos, essa abordagem é exagerada, mas quando a consistencia é absoluta, não há alternativa.

Qual estrategia escolher?

Não existe uma resposta unica. A escolha depende de tres perguntas: qual a tolerancia a dados desatualizados, qual a frequencia de escrita versus leitura, e qual o impacto de uma inconsistencia. Para dados com baixa taxa de atualização e tolerancia a atraso, TTL resolve. Para consistencia imediata com leituras frequentes, write-through. Para alta taxa de escrita e perda aceitavel, write-back. Para sistemas distribuidos, invalidation por evento ou versionamento. Comece com a mais simples que atende ao SLA e evolua conforme a necessidade. O erro mais comum é adotar a estrategia mais complexa antes de medir o problema real.

Perguntas Frequentes

O que é cache invalidation?

Cache invalidation é o processo de remover ou atualizar dados armazenados em cache quando a fonte original muda. Sem invalidation, o cache pode servir dados obsoletos, o que compromete a consistencia. As estrategias variam entre expiração por tempo, atualização sincrona ou eventos.

Qual a diferenca entre write-through e write-back?

Write-through atualiza o cache e o banco na mesma operação, garantindo consistencia imediata mas com maior latência de escrita. Write-back atualiza apenas o cache e persiste no banco depois, oferecendo performance melhor mas com risco de perda de dados se o cache falhar.

TTL é suficiente para garantir consistencia?

TTL garante que o dado expira em um tempo definido, mas não garante consistencia imediata. Se o negócio tolera atraso, TTL é suficiente. Para consistencia em tempo real, é preciso combinar TTL com outras estrategias, como invalidation por evento.

Como escolher o valor do TTL?

O TTL deve ser menor ou igual ao SLA de frescor do dado. Se o dado pode ficar desatualizado por no maximo 5 minutos, o TTL deve ser de 5 minutos ou menos. Teste com valores diferentes e monitore o impacto na carga do banco.

O que é cache-aside?

Cache-aside é uma estrategia onde o aplicativo gerencia o cache manualmente: verifica o cache, busca no banco se não houver, e invalida apos escritas. É flexivel e facil de implementar, mas exige disciplina para evitar dados obsoletos.

Quando usar versionamento de cache?

Versionamento é recomendado quando a consistencia absoluta é critica e não pode haver corrida entre escrita e leitura. É comum em sistemas de configuracao distribuida, mas é complexo e usa mais memoria. Use apenas se o problema justificar a complexidade.