Padroes de cache aplicacao sao estrategias para guardar dados temporarios em memoria ou disco, evitando idas desnecessarias ao banco ou a APIs externas. Quando bem aplicados, cortam a latencia de milissegundos para microssegundos. Mas nao existe bala de prata: cada padrao resolve um problema e cria um trade-off. Abaixo, os 9 mais usados, do mais simples ao mais sofisticado.
1. Cache-aside (lazy loading)
O aplicativo consulta o cache primeiro. Se nao achar, busca na fonte, popula o cache e devolve. Simples e eficiente para leituras frequentes. O risco: dados podem ficar obsoletos se a fonte mudar sem avisar. Use com TTL (tempo de vida) curto para minimizar.
2. Read-through
Semelhante ao cache-aside, mas a logica de busca e populamento fica dentro da camada de cache, nao no codigo da aplicacao. O cache se comporta como um proxy: se a chave nao existe, ele busca na fonte, grava e responde. Menos codigo no app, mas exige uma biblioteca que suporte isso.
3. Write-through
Cada escrita vai primeiro para o cache e depois para o banco. Garante que o cache esteja sempre atualizado, mas adiciona latencia na escrita. Ideal quando leitura e escrita sao equilibradas e a consistencia imediata importa mais que a velocidade de escrita.
4. Write-back (write-behind)
A escrita vai so para o cache e, assincronamente, e persistida no banco. Reduz drasticamente a latencia de escrita, mas ha risco de perda de dados se o cache cair antes da sincronizacao. Use quando a durabilidade pode ser relaxada, como em contadores de visualizacao.
5. Write-around
Combina cache-aside para leitura e escrita direta no banco. O cache so e populado quando ha um miss. Evita poluir o cache com dados que nunca serao lidos, mas leituras imediatamente apos escrita podem falhar. Bom para dados de baixa frequencia de acesso.
6. TTL (time-to-live) com expiracao
Nao e um padrao isolado, mas uma politica essencial. Cada chave tem um tempo de vida; ao expirar, o cache e recarregado. Define o equilibrio entre frescor e performance. TTL muito curto anula o cache; muito longo serve dados velhos.
7. Eviction (politica de remocao)
Quando o cache enche, algo precisa sair. FIFO (primeiro a entrar, primeiro a sair), LRU (menos recentemente usado) e LFU (menos frequentemente usado) sao os comuns. LRU costuma ser o melhor custo-beneficio para a maioria dos casos, mas exige medicao do padrao de acesso.
8. Cache de invalidade por evento
Em vez de TTL, o proprio aplicativo invalida a chave quando a fonte muda. Garante consistencia forte, mas exige que o codigo saiba quando algo mudou. Em sistemas distribuidos, vira um problema de sincronizacao. Use com mensageria ou eventos de dominio.
9. Cache distribuido
Quando uma instancia so nao resolve, usa-se um cache compartilhado (Redis, Memcached). Todas as instancias leem o mesmo cache, evitando duplicacao e inconsistencia. O custo: uma chamada de rede extra, que ainda e mais rapida que ir ao banco.
Qual escolher?
Comece com cache-aside e TTL. Se a escrita for frequente, adicione write-through ou write-back. Se a consistencia for critica, invalide por evento. Teste com metricas reais: latencia percentil 95 e taxa de hit. Sem medicao, qualquer padrao e chute.
FAQ
O que e um padrao de cache em aplicacao?
E uma estrategia predefinida para armazenar e recuperar dados temporarios, reduzindo o acesso a fontes lentas. Cada padrao define quando o cache e populado, atualizado e removido. Exemplos: cache-aside, read-through, write-through.
Qual a diferenca entre cache-aside e read-through?
No cache-aside, o codigo da aplicacao gerencia a logica de buscar e popular o cache. No read-through, essa logica fica na propria camada de cache, que busca a fonte automaticamente em caso de miss. O read-through exige suporte da biblioteca.
Como reduzir a latencia com cache?
Identifique as leituras mais frequentes e demoradas, aplique cache-aside com TTL adequado e meca o impacto no percentil 95. Evite cacar tudo indiscriminadamente, pois isso aumenta a complexidade e o risco de dados obsoletos.
O que e TTL em cache?
Time-to-live: o tempo que um item fica valido no cache antes de expirar. Ao expirar, a proxima leitura busca na fonte e atualiza o cache. TTL curto traz dados mais frescos, TTL longo melhora a performance, mas pode servir dados antigos.
Qual a melhor politica de remocao de cache?
Depende do padrao de acesso. LRU (menos recentemente usado) e a mais comum e eficiente para a maioria dos casos. LFU funciona bem quando alguns itens sao muito mais acessados. FIFO e simples, mas pode remover dados ainda uteis.
Cache distribuido vale a pena?
Sim, quando a aplicacao roda em multiplas instancias e precisa de consistencia. Redis e Memcached sao opcoes populares. O custo e uma chamada de rede, que ainda e mais rapida que um acesso ao banco, mas nao deve ser usada para dados minusculos.