# Thundering Herd e Cache Penetration: Por Que o Site Cai Sempre no Mesmo Horário

> Quatro modos de falha de cache explicam por que um site cai no mesmo horário todo dia, por que um bot varrendo URLs inexistentes derruba o servidor, e o vocabulário para conversar com a infraestrutura durante uma campanha.

- Tipo: Artigo
- Autor: Dionatha Rodrigues
- Publicado em: 2026-08-29 · Atualizado em: 2026-09-21
- URL: https://clubmartech.com.br/blog/thundering-herd-cache-penetration/

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](https://clubmartech.com.br/blog/retry-backoff-jitter-integracao/): 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.

![Checklist: Repovoamento proativo, Jitter nos TTLs, Cluster redundante.](https://clubmartech.com.br/wp-content/uploads/2026/10/cmt-diagrama-28796-082f5c94.webp)

*O que conferir no cache antes da campanha.*

## 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.