Cache existe para poupar o banco de dados de trabalho repetido: em vez de recalcular a mesma resposta toda vez, ela fica guardada por um tempo, pronta para ser servida instantaneamente. Funciona bem na maior parte do tempo — até que algo no padrão de uso quebra a suposição por trás do cache, e o sistema inteiro sente o impacto de uma vez. Existem quatro formas clássicas de isso acontecer, e cada uma tem um sintoma reconhecível na operação de marketing.
Por que cache falha em modos específicos, não aleatórios
Um cache saudável reduz drasticamente a carga sobre o banco de dados, porque a maioria das leituras é respondida a partir da memória rápida, sem tocar a origem. O problema aparece quando uma condição específica faz muitas requisições baterem no banco ao mesmo tempo, anulando exatamente a proteção que o cache deveria oferecer. O termo “thundering herd” — manada trovejante — vem de sistemas operacionais dos anos 1990, descrevendo o momento em que múltiplos processos são acordados simultaneamente para competir por um único recurso, a maioria em vão.
Os quatro modos de falha, traduzidos para marketing
| Modo | O que é tecnicamente | Sintoma reconhecível | Solução |
|---|---|---|---|
| Thundering herd | Muitas chaves de cache expiram no mesmo instante, e todas as requisições batem no banco simultaneamente | Site cai sempre no mesmo horário — o momento em que um bloco grande de cache expira junto | Jitter no TTL: cada chave expira num instante levemente aleatório, não todas no mesmo segundo |
| Cache penetration | Consultas repetidas para dado que não existe em lugar nenhum — nem cache, nem banco | Bot ou scraper varrendo URLs inexistentes derruba o servidor, porque cada consulta sempre vai até o banco | Cachear o “não existe” — guardar também a resposta negativa, com TTL curto |
| Cache breakdown | Uma única chave muito acessada (“quente”) expira, e todo o tráfego que dependia dela bate no banco de uma vez | Pico súbito de lentidão num produto ou página específica durante uma campanha ativa | Nunca deixar a chave quente expirar sem repovoar antes — renovação proativa em vez de esperar o TTL zerar |
| Cache crash | O próprio serviço de cache cai, e absolutamente tudo passa a bater direto no banco | Queda total do site sob carga, sem aviso prévio, geralmente durante pico de tráfego | Circuit breaker (interromper temporariamente o fluxo para o banco) e cluster de cache redundante |
Thundering herd: o site que cai sempre na mesma hora
Se um site institucional ou e-commerce apresenta lentidão ou queda recorrente sempre próximo do mesmo horário — meia-noite, início de hora cheia, ou algum intervalo fixo — a causa mais provável não é coincidência de tráfego. É que um bloco grande de chaves de cache foi configurado para expirar exatamente naquele momento, e quando expiram juntas, todas as requisições que dependiam delas batem no banco de dados simultaneamente, recriando artificialmente um pico de carga.
A solução — adicionar jitter ao tempo de expiração (TTL) — é o mesmo princípio usado em retry com jitter: em vez de “expire em exatamente 60 minutos”, a regra vira “expire entre 55 e 65 minutos, sorteado por chave”. Isso espalha as expirações ao longo de uma janela, em vez de concentrá-las num único instante — quebrando a sincronização que causa o pico.
Cache penetration: quando o bot descobre o ponto fraco
Cache normalmente guarda respostas positivas — “aqui está o produto X”. Mas o que acontece quando alguém pede repetidamente por algo que não existe? Se o sistema só cacheia respostas positivas, toda consulta a um item inexistente vai direto ao banco, porque não há nada em cache para servir — nem a informação de que aquilo não existe.
Um bot ou scraper mal-intencionado (ou mal configurado) que varre sistematicamente IDs de produto sequenciais, muitos dos quais não existem, explora exatamente essa lacuna: cada consulta a um ID inexistente ignora completamente o cache e recai sobre o banco de dados, que pode não aguentar o volume. De fora, parece um ataque de negação de serviço; na raiz, é frequentemente apenas a ausência de uma proteção simples — cachear também a resposta “não encontrado”, com um tempo de expiração curto, para que consultas repetidas ao mesmo item inexistente também sejam absorvidas pelo cache.
Cache breakdown: quando o produto da campanha é vítima do próprio sucesso
Esse modo é o mais relevante durante campanhas de alto tráfego direcionado. Imagine uma chave de cache extremamente popular — a página do produto que está na campanha do dia, ou o cupom mais usado do momento. Enquanto essa chave está em cache, ela absorve tranquilamente um volume altíssimo de acesso. O problema acontece exatamente no instante em que ela expira: toda a demanda que estava sendo tranquilamente absorvida pelo cache passa, de uma só vez, a bater direto no banco, gerando um pico concentrado numa única página ou produto.
A diferença para o thundering herd é de escopo: ali, muitas chaves expiram juntas; aqui, é uma única chave extremamente quente que causa o mesmo efeito sozinha, por concentrar desproporcionalmente o tráfego. A solução prática é nunca deixar uma chave identificada como “quente” expirar sem que o sistema já tenha uma versão renovada pronta — uma estratégia de repovoamento proativo, em vez de esperar passivamente o tempo de expiração zerar.
Cache crash: o cenário mais severo
O último modo é o mais direto: o próprio serviço de cache (Redis, Memcached, ou equivalente) cai — por sobrecarga, falha de infraestrutura, ou erro de configuração. Sem cache algum, toda requisição passa a bater diretamente no banco de dados, incluindo o tráfego normal que antes era absorvido tranquilamente. O resultado costuma ser queda total do site, não apenas lentidão pontual.
As duas defesas recomendadas trabalham em conjunto: um circuit breaker, que detecta a sobrecarga do banco e interrompe temporariamente parte do tráfego (servindo uma versão degradada da página, por exemplo) em vez de deixar o banco afundar completamente; e um cluster de cache redundante, para que a falha de uma instância não derrube a camada de cache inteira de uma vez.
Um quinto nome que ajuda a completar o vocabulário: cache stampede
Alguns materiais técnicos usam o termo cache stampede como sinônimo amplo que engloba tanto o thundering herd quanto o cache breakdown — a ideia geral de “muitas requisições correndo simultaneamente para recomputar o mesmo dado ou dados relacionados, sobrecarregando a origem”. Não é essencial memorizar essa quarta ou quinta nomenclatura, mas reconhecer o termo evita confusão ao ler documentação técnica de diferentes fornecedores de cache, cada um às vezes usando um vocabulário ligeiramente distinto para descrever fenômenos muito parecidos entre si.
A técnica de defesa mais citada contra qualquer variante de stampede é o chamado lock de recomputação: quando uma chave expira e múltiplas requisições chegam simultaneamente pedindo o mesmo dado, apenas a primeira requisição é autorizada a de fato consultar o banco e recalcular o valor; todas as demais aguardam brevemente e recebem o resultado assim que ele fica pronto, em vez de cada uma delas também bater no banco de forma redundante. Esse mecanismo simples reduz drasticamente o pico de carga no momento exato da expiração, sem exigir mudança na lógica de negócio da aplicação.
O vocabulário para a conversa com infraestrutura durante um incidente
Quando o site cai durante uma campanha de grande volume, o instinto é reportar “está fora do ar” e esperar. Ter esses quatro nomes à mão muda a qualidade da conversa com o time técnico ou com o fornecedor de hospedagem — a pergunta deixa de ser genérica e passa a apontar direção de investigação:
- “A queda coincide com algum horário fixo de expiração de cache? Pode ser thundering herd.”
- “Estamos recebendo tráfego de bot em URLs que não existem? Pode ser cache penetration.”
- “Tem algum produto ou página específica concentrando o pico? Pode ser cache breakdown numa chave quente.”
- “O serviço de cache em si está de pé? Se caiu, é cache crash, e a prioridade é isolar o banco com um circuit breaker.”
Essas quatro hipóteses cobrem a maioria dos incidentes de “site caiu sob carga” relacionados a cache — e permitem que quem não é da área técnica participe do diagnóstico em vez de apenas esperar a resolução.
Um quinto sintoma que combina os quatro modos
Vale um alerta prático: incidentes reais raramente se apresentam como um modo puro e isolado — é comum que uma queda comece como cache breakdown numa página de campanha, e a sobrecarga resultante no banco acabe derrubando o próprio serviço de cache (cache crash), que por sua vez faz todo o resto do site cair junto, mesmo páginas que não tinham relação nenhuma com a campanha original. Esse efeito em cascata é o motivo pelo qual pequenas negligências de configuração de cache em uma única página de alto tráfego podem, em teoria, comprometer a disponibilidade do site inteiro.
Isso reforça por que a defesa mais robusta não é escolher apenas uma das quatro soluções, mas combinar várias: jitter no TTL para evitar sincronização, cache do “não encontrado” para páginas inexistentes, renovação proativa das chaves mais quentes, e isolamento (circuit breaker, cluster redundante) para conter o efeito cascata quando, apesar de tudo, alguma coisa ainda falhar.
Antes da próxima campanha de grande volume
Vale antecipar essas quatro perguntas antes de uma campanha de tráfego alto, não durante o incidente. Perguntar ao time técnico se a página promocional principal tem estratégia de repovoamento de cache proativo (contra cache breakdown), se os TTLs têm jitter configurado (contra thundering herd), e se existe cluster redundante de cache (contra cache crash) é uma checagem de minutos que pode evitar horas de indisponibilidade no pico exato em que o tráfego mais importa.
Próximos passos para revisar sua camada de cache
A ação concreta: se seu site já teve alguma queda ou lentidão recorrente sob carga, revise o histórico de incidentes com essas quatro categorias em mãos e tente classificar qual delas mais se parece com o que aconteceu. Isso já direciona a pergunta certa para o time técnico ou para a agência de infraestrutura, em vez de um genérico “precisamos de mais servidor” — que raramente é a causa real.
Se uma campanha de grande volume está no calendário, use as quatro perguntas da seção anterior como checklist de pré-lançamento junto ao time técnico, em vez de descobrir a resposta em produção.
