Invalidação de cache sem dor de cabeça
· 7 min
Invalidação de cache é famosa por ser "um dos dois problemas difíceis" da computação, mas o jeito mais comum dela dar errado na prática não é escolher o algoritmo errado, é nunca decidir explicitamente quem é dono de invalidar o quê.
TTL sozinho é uma aposta, não uma estratégia
Um TTL curto mantém o dado fresco às custas de bater no banco com mais frequência; um TTL longo economiza carga às custas de servir dado desatualizado por mais tempo. Usar só TTL funciona bem quando esse período de inconsistência é genuinamente aceitável pro caso de uso, e vira um problema silencioso quando não é, porque o sistema nunca avisa que está servindo algo velho.
Invalidação por evento: quem escreve avisa
Na invalidação por evento, o próprio código que altera o dado é responsável por apagar ou atualizar a entrada de cache correspondente, dando consistência quase imediata. O custo é acoplamento: todo caminho de escrita precisa saber quais chaves de cache dependem daquele dado, e esquecer uma delas é o jeito mais comum desse padrão falhar silenciosamente.
Cache stampede: quando todo mundo bate no banco ao mesmo tempo
Quando uma chave muito acessada expira, múltiplas requisições concorrentes podem sentir o miss ao mesmo tempo e disparar todas juntas pro banco pra repopular o cache, uma pequena expiração vira um pico de carga real. As mitigações mais comuns são coalescer requisições (só uma delas de fato recalcula, as outras esperam o resultado) e expiração antecipada probabilística, renovando a entrada um pouco antes do prazo real pra espalhar a carga no tempo.
Cache-aside vs write-through
No padrão cache-aside, a aplicação consulta o cache, cai pro banco no miss e popula o cache depois, simples, mas com uma janela onde cache e banco podem divergir. No write-through, toda escrita passa pela camada de cache, que mantém os dois sincronizados sempre, mais consistente, ao custo de mais complexidade na camada de escrita.
A pergunta que evita a dor de cabeça
Antes de escolher uma estratégia de invalidação, vale decidir explicitamente, pra cada dado cacheado, quem é responsável por invalidá-lo e sob qual evento. A maioria dos bugs de cache não vem do algoritmo errado, vem dessa responsabilidade nunca ter sido decidida de verdade.