Cache em camadas: Redis, CDN e cache de aplicação sem servir dado velho

Cache é a alavanca de performance mais barata que existe: em vez de recalcular ou rebuscar um dado, você o guarda pronto e o entrega em microssegundos. Também é a fonte de uma das piores classes de bug em produção, o dado velho servido com cara de fresco. O usuário atualizou o preço, mas a tela mostra o antigo. O cliente cancelou o plano, mas a API ainda o trata como ativo. Cache mal desenhado não é performance, é inconsistência disfarçada.

A boa notícia é que cache não é uma decisão única, e sim um conjunto de camadas que se complementam. Este guia percorre as três principais (cache de aplicação, Redis como cache distribuído e CDN na borda), as estratégias de leitura e escrita, e o tema que separa o cache profissional do amador: como invalidar sem servir dado velho.

Por que pensar em camadas

Cada camada de cache fica mais perto do usuário e mais barata de consultar conforme você sobe. A ideia é responder o mais cedo possível no caminho da requisição, tocando o banco de dados apenas quando nenhuma camada anterior tem a resposta.

Camada	Onde vive	Latência típica	Escopo	Melhor para
Cache de aplicação	Memória do processo	Nanossegundos	Um servidor	Dados quentes e imutáveis
Cache distribuído (Redis)	Serviço em memória compartilhado	Submilissegundo	Todos os servidores	Sessões, resultados de query, contadores
CDN	Borda, perto do usuário	Milissegundos	Global	Estáticos e respostas cacheáveis

O princípio é hierárquico: a requisição consulta a camada mais rápida primeiro e só desce para a próxima em caso de miss. Quanto mais perto do usuário você resolve, menos carga chega ao seu banco e menor a latência percebida.

Camada 1: cache de aplicação (in-process)

O cache mais rápido é o que vive dentro do próprio processo, na memória da aplicação. Não há rede no meio, então o acesso é praticamente instantâneo. É ideal para dados pequenos, muito lidos e que raramente mudam: tabelas de configuração, listas de países, feature flags, resultados de cálculos caros.

O limite é a natureza local. Cada instância da aplicação tem seu próprio cache, então uma atualização em um servidor não se reflete nos outros automaticamente. Em uma frota de dez instâncias, você pode ter dez versões ligeiramente diferentes do mesmo dado. Por isso o cache in-process combina bem com dados de baixa volatilidade e TTL curto, ou com um mecanismo de invalidação que avisa todas as instâncias quando algo muda.

Camada 2: Redis como cache distribuído

Quando o cache precisa ser compartilhado entre todas as instâncias, entra um cache distribuído em memória, e o Redis é o padrão de mercado. Todos os servidores consultam o mesmo Redis, então há uma visão única e consistente do dado cacheado. É onde ficam sessões de usuário, resultados de queries pesadas, agregações, contadores e respostas de API que valem a pena reaproveitar.

Vale um aviso de escopo: aqui tratamos Redis como cache, não como fila de mensagens. Redis também serve para filas e streams, mas esse é assunto de arquitetura de mensageria, não de cache. No papel de cache, o que importa é guardar valores com chave e prazo de validade.

Cache-aside: o padrão mais comum

O padrão dominante é o cache-aside (também chamado lazy loading). A lógica é direta:

• A aplicação pede o dado ao cache.
• Se está lá (cache hit), retorna na hora.
• Se não está (cache miss), busca no banco, grava no cache com um TTL e retorna.

Assim, apenas o primeiro acesso paga o custo do banco; os seguintes vêm do Redis até o TTL expirar. É simples, resiliente (se o cache cai, a aplicação ainda funciona indo ao banco) e cobre a maioria dos casos de leitura intensa.

TTL: o prazo de validade de cada chave

O TTL (time to live) define por quanto tempo um valor cacheado é considerado válido. Escolher o TTL é escolher conscientemente quanto de desatualização você tolera. Um catálogo de produtos aguenta minutos; um saldo financeiro, quase nada. A regra prática: quanto mais crítico e mutável o dado, menor o TTL. Dados imutáveis podem ter TTL longo ou nem expirar.

Camada 3: CDN na borda

A CDN (Content Delivery Network) empurra o cache para o extremo do caminho, servidores espalhados pelo mundo, perto fisicamente do usuário. Uma requisição de São Paulo é atendida por um nó em São Paulo, não por um servidor em Virginia. Além de estáticos óbvios (imagens, CSS, JavaScript, vídeos), CDNs modernas cacheiam também respostas dinâmicas cacheáveis, como uma página de produto que muda poucas vezes ao dia.

O controle fino vem dos headers HTTP de cache:

• Cache-Control: max-age=3600 diz por quanto tempo a resposta pode ser cacheada.
• ETag e Last-Modified permitem revalidação: o cliente pergunta "mudou?" e recebe um 304 Not Modified barato quando nada mudou.
• stale-while-revalidate serve a versão atual imediatamente enquanto busca a nova em segundo plano, combinando velocidade e frescor.

O problema central: invalidação sem servir dado velho

Existe uma frase famosa na engenharia: as duas coisas difíceis em computação são nomear coisas e invalidar cache. Guardar o dado é fácil; saber a hora certa de descartá-lo é o desafio real. Estratégias de invalidação:

• Expiração por TTL: deixa o dado morrer sozinho após o prazo. Simples, mas há uma janela em que você serve dado velho até o TTL vencer.
• Invalidação explícita: ao alterar o dado na origem, você apaga (ou reescreve) a chave correspondente no cache imediatamente. Precisa, porém exige disciplina para não esquecer nenhuma chave relacionada.
• Write-through: toda escrita atualiza banco e cache na mesma operação, mantendo os dois sempre sincronizados, ao custo de escritas mais lentas.
• Versionamento de chave: em vez de invalidar, você muda a chave (por exemplo, incluindo um número de versão ou timestamp). A chave antiga simplesmente deixa de ser consultada e expira sozinha.

A escolha depende de quanto a aplicação tolera de inconsistência. Para dados que não podem aparecer velhos, prefira invalidação explícita ou write-through. Para dados que toleram alguns segundos de atraso, o TTL resolve com muito menos complexidade.

Armadilhas que derrubam sistemas em produção

Cache mal operado cria falhas próprias, algumas capazes de derrubar o banco que ele deveria proteger:

• Cache stampede (thundering herd): uma chave popular expira e mil requisições simultâneas vão ao banco ao mesmo tempo para recalculá-la. Mitigue com um lock que deixa só uma requisição recalcular enquanto as outras esperam, ou renovando a chave um pouco antes de expirar.
• Cache penetration: requisições por chaves que não existem furam o cache e batem sempre no banco. Cacheie também o resultado "não existe", por um TTL curto.
• Inconsistência entre camadas: o dado mudou no banco, mas a CDN ainda serve a versão antiga. Coordene a invalidação de todas as camadas, da borda ao Redis.
• Cachear o que não devia: dados por usuário ou sensíveis cacheados em camada compartilhada viram vazamento entre usuários. Separe cache público de cache privado com rigor.

Como montar sua estratégia de cache

Um roteiro pragmático, sem exageros:

• Comece pela origem. Um banco bem indexado reduz a necessidade de cache. Cache não conserta query ruim, só esconde o problema por um tempo.
• Cacheie o quente, não tudo. Meça o que é lido com frequência e caro de produzir; é ali que o cache paga.
• Defina o TTL pela tolerância a dado velho de cada dado, não por um valor global.
• Planeje a invalidação antes de cachear. Se você não sabe como vai invalidar uma chave, ainda não está pronto para cacheá-la.
• Monitore o hit ratio. Um cache com baixa taxa de acerto só adiciona latência e complexidade sem entregar o ganho esperado.

Cache é uma das ferramentas de maior retorno em um SaaS, e também uma das que mais silenciosamente introduz bugs de consistência. A diferença entre os dois desfechos não está na tecnologia (Redis e CDN são maduros e confiáveis), e sim no cuidado com TTL, invalidação e escopo. Feito com disciplina, o cache entrega respostas instantâneas sem nunca mentir para o usuário.

---

Seu produto está lento ou servindo dado desatualizado? Na ConstructorTI, desenhamos estratégias de cache em camadas com invalidação correta desde o início, para você ganhar performance sem trocar velocidade por inconsistência. Se as suas telas às vezes mostram dado velho ou o banco sofre em horário de pico, fale com a nossa engenharia e receba um diagnóstico técnico da sua camada de cache.