Cache como estratégia de negócio: quando a velocidade vira vantagem competitiva

Por que cache é decisão de negócio

Latência mata conversão. Um atraso de 100ms no carregamento de uma página de produto pode reduzir a taxa de conversão em 1%. Para um e-commerce com R$ 10 milhões de GMV mensal, isso representa R$ 100 mil perdidos mensalmente — por 100 milissegundos. Cache bem projetado é uma das alavancas técnicas de maior impacto por menor custo disponível em sistemas de produção.

Mas cache não é gratuito. Cada camada introduz complexidade de invalidação, risco de dados obsoletos e superfície adicional de falha. A estratégia correta é saber onde cada tipo de cache resolve um problema real — e onde ele cria problemas novos.

As camadas de cache e quando usar cada uma

• CDN (Content Delivery Network) — para assets estáticos (imagens, JS, CSS) e respostas de API que não variam por usuário. Serve o conteúdo do ponto de presença mais próximo do usuário, eliminando latência de rede. Ferramentas: Cloudflare, AWS CloudFront, Fastly. TTL longo (horas a dias) com invalidação por deploy.
• Application cache com Redis — para resultados de queries pesadas, sessões de usuário, rate limiting e objetos computacionalmente caros. Redis opera em memória com latência de submilissegundos. É o nível mais flexível: você controla exatamente o que cacheia, por quanto tempo e como invalida.
• Database query cache — presente em bancos relacionais (MySQL, PostgreSQL) e NoSQL. Cacheia o resultado de queries idênticas. Eficaz para leituras repetidas com dados que mudam raramente, mas pode ser prejudicial em workloads de escrita intensiva por overhead de invalidação.
• In-process / local cache — cache dentro da própria aplicação, em memória do processo. Latência zero, mas cria inconsistência em ambientes com múltiplas instâncias. Use apenas para dados verdadeiramente estáticos (configurações, tabelas de referência imutáveis).

As armadilhas de invalidação que todo time cai

Phil Karlton disse que existem apenas dois problemas difíceis em ciência da computação: invalidação de cache e nomear coisas. A invalidação é difícil porque requer que o sistema que escreve os dados saiba — e notifique — todos os sistemas que cachearam versões antigas.

• Cache poisoning — um dado incorreto entra no cache e é servido até o TTL expirar. Em caches com TTL longo, o problema pode persistir horas. Solução: validação de integridade antes de cachear e mecanismo de invalidação explícita.
• Thundering herd — quando um item expirado é requisitado simultaneamente por centenas de requisições, todas vão ao banco ao mesmo tempo. Solução: mutex lock na renovação do cache (só uma requisição reconstrói, as demais aguardam) ou stale-while-revalidate (serve o dado obsoleto enquanto renova em background).
• Cache stampede em deploy — quando a aplicação é redeploy, o cache quente é descartado e todas as requisições vão ao banco simultaneamente. Solução: aquecimento de cache (cache warming) antes de rotear tráfego para as novas instâncias.

Impacto no custo de infraestrutura

Além da performance, cache bem projetado tem impacto direto no custo operacional. Cada requisição que retorna do cache não consome compute no banco de dados. Em sistemas com bancos RDS ou Aurora, onde o custo escala com IOPS e conexões, um hit rate de cache de 80-90% pode reduzir o custo de banco em 50-70%.

A métrica que monitora a eficiência do cache é o hit rate: percentual de requisições atendidas pelo cache sem ir ao banco. Um hit rate abaixo de 70% geralmente indica que a estratégia de cacheamento precisa revisão — seja no que está sendo cacheado, no TTL ou na lógica de invalidação.