Estrategias de cache sao tecnicas que armazenam copias de dados frequentemente acessados em memorias rapidas (RAM, SSD) para evitar consultas repetidas ao banco de dados ou disco. As principais incluem cache local, cache distribuido, CDN, write-through, write-behind, cache-aside e read-through. Cada uma resolve um cenario especifico de leitura/escrita e impacto na consistencia dos dados.
1. Cache Local (In-Process)
O cache local armazena dados na memoria do proprio processo da aplicacao, como um dicionario em memoria. E a estrategia mais rapida, latencia de microssegundos, porque nao envolve rede. Porem, o espaco e limitado a RAM disponivel no processo, e cada instancia da aplicacao tem seu proprio cache, o que pode gerar inconsistencia entre nos. Funciona bem para dados que mudam raramente, como configuracoes de sistema ou listas de paises. Um criterio pratico: se o dado cabe em 10% da RAM do processo e nao precisa ser sincronizado entre servidores, cache local resolve.
2. Cache Distribuido (Redis, Memcached)
Cache distribuido usa um servico externo (como Redis ou Memcached) acessado via rede, compartilhado entre multiplas instancias da aplicacao. A latencia e maior que o local (milissegundos), mas o armazenamento e escalavel horizontalmente. Ideal para sessoes de usuario, resultados de consultas SQL pesadas ou dados que precisam ser consistentes entre nos. Um contraexemplo: se a rede cai, o cache fica indisponivel, entao sempre tenha um fallback para o banco.
3. CDN (Content Delivery Network)
CDN armazena copias de recursos estaticos (imagens, CSS, JS, videos) em servidores geograficamente distribuidos. Reduz latencia para usuarios finais e descarrega o servidor de origem. E a estrategia mais eficaz para conteudo publico que nao muda com frequencia. Um numero concreto: CDNs como Cloudflare podem reduzir o trafego no servidor de origem em ate 70% para recursos estaticos. O ponto critico e configurar o TTL (time-to-live) correto, muito curto anula o beneficio, muito longo pode servir conteudo desatualizado.
4. Cache Write-Through
Na estrategia write-through, toda escrita no banco de dados e imediatamente refletida no cache. Isso garante que o cache esteja sempre atualizado, mas cada escrita tem latencia maior (precisa escrever em dois lugares). E ideal para sistemas com alta taxa de leitura e baixa taxa de escrita, onde a consistencia imediata e critica. Um exemplo: atualizacao de saldo bancario, o dado deve estar correto na proxima leitura. A desvantagem e que escritas frequentes sobrecarregam o cache com dados que talvez nunca sejam lidos.
5. Cache Write-Behind (Write-Back)
Write-behind faz a escrita primeiro no cache e depois, assincronamente, no banco de dados. A latencia de escrita e baixa para o usuario, mas ha risco de perda de dados se o cache falhar antes da persistencia. Funciona bem para logs, contadores de visualizacao ou dados onde uma perda pequena e aceitavel. Um criterio: use write-behind apenas quando a consistencia eventual for toleravel e o sistema tiver mecanismos de recuperacao (como filas com persistencia local).
6. Cache-Aside (Lazy Loading)
Cache-aside e a estrategia mais comum: a aplicacao verifica o cache primeiro; se nao encontrar (cache miss), busca no banco e armazena no cache para proximas requisicoes. E simples de implementar e eficiente para dados com padrao de acesso imprevisivel. O problema e o cache stampede, quando muitos requests batem no banco ao mesmo tempo apos uma expiracao de cache. Para mitigar, use lock distribuido ou expiracao com jitter (variacao aleatoria no TTL).
7. Read-Through
Read-through e similar ao cache-aside, mas a logica de buscar do banco e encapsulada no proprio sistema de cache (como um provedor de cache que sabe carregar dados). A aplicacao apenas chama o cache, que internamente gerencia o miss. Simplifica o codigo da aplicacao, mas exige que o cache suporte essa funcionalidade (Redis com scripts Lua, por exemplo). E util quando voce quer centralizar a logica de cache e evitar duplicacao entre servicos.
Qual Estrategia Escolher?
Nao ha uma estrategia universal. Para recursos estaticos publicos, comece com CDN. Para dados de sessao ou consultas frequentes entre servidores, cache distribuido com Redis. Para dados de configuracao que mudam pouco, cache local. Combine estrategias: use cache local para dados quentes e distribuido como fallback. O importante e medir o hit ratio (porcentagem de requests servidos pelo cache), se estiver abaixo de 80%, reveja o TTL ou a estrategia.
FAQ
O que e cache miss?
Cache miss ocorre quando o dado solicitado nao esta no cache. A aplicacao precisa buscar no banco de dados ou disco, o que aumenta a latencia. Um alto indice de cache miss indica que a estrategia ou configuracao de TTL precisa ser ajustada.
Qual a diferenca entre cache local e distribuido?
Cache local armazena dados na memoria do proprio processo da aplicacao, sem acesso de rede. Cache distribuido usa um servico externo (Redis, Memcached) compartilhado entre multiplos servidores. O local e mais rapido, mas nao escala entre nos; o distribuido escala, mas tem latencia de rede.
Como evitar cache stampede?
Cache stampede acontece quando muitos requests batem no banco ao mesmo tempo apos expiracao do cache. Para evitar, use lock distribuido (apenas um request recarrega o cache), expiracao com jitter (variacao aleatoria no TTL) ou cache com renovacao proativa (atualiza antes de expirar).
O que e TTL no cache?
TTL (time-to-live) e o tempo que um dado permanece valido no cache antes de ser removido ou atualizado. Configurar TTL muito curto reduz o beneficio do cache; muito longo pode servir dados desatualizados. O valor ideal depende da frequencia de atualizacao dos dados.
Cache write-through vs write-behind: qual usar?
Write-through garante consistencia imediata entre cache e banco, mas aumenta latencia de escrita. Write-behind reduz latencia de escrita, mas arrisca perda de dados se o cache falhar. Escolha write-through para dados criticos (financeiros) e write-behind para dados tolerantes a perda (logs, metricas).
CDN substitui cache de aplicacao?
Nao. CDN e otima para recursos estaticos (imagens, CSS, JS), mas nao substitui cache de dados dinamicos (sessoes, consultas SQL). Use CDN para o front-end estatico e cache distribuido (Redis) para dados gerados pela aplicacao.