Por que a loja cai na Black Friday (e quase nunca é o servidor)
Todo ano a mesma cena: o time sobe a máquina, dobra a CPU, e a loja cai do mesmo jeito. O gargalo costuma estar três camadas acima.
A conversa começa sempre igual. "A loja caiu no pico. Precisamos de um servidor maior." Em oito de cada dez vezes, o servidor maior resolve por uma hora e o problema volta no próximo pico — porque o gargalo nunca foi capacidade.
O suspeito de sempre: uma consulta por item
A página de categoria lista 48 produtos. Para cada um, o código busca o preço promocional. São 48 idas ao banco onde deveria haver uma. Em desenvolvimento, com três produtos de teste, ninguém percebe: 3 consultas de 2 ms somam 6 ms. Em produção, 48 consultas com o banco sob carga somam 900 ms — e isso é só uma página, de um usuário.
Multiplique por mil pessoas simultâneas e o banco não está lento: está respondendo 48 mil perguntas que deveriam ter sido uma.
O jeito de achar isso não é olhar gráfico de CPU. É ligar o log de consultas por requisição em homologação e olhar o número. Se uma página faz mais de vinte consultas, você já achou o problema.
O segundo suspeito: cache que não existe onde importa
Catálogo muda pouco. Preço muda algumas vezes por dia. Estoque muda a todo momento. Tratar os três com a mesma política de cache é o erro clássico — e leva o time a desligar o cache inteiro quando o estoque aparece errado.
O que funciona é separar por volatilidade: o catálogo pode ficar minutos em cache de borda, o preço segundos, e o estoque nada — mas o estoque é o único dado que precisa ir ao banco. A página inteira deixa de depender da consulta mais cara que ela contém.
O terceiro: o deploy no dia errado
Subir versão na véspera do pico não é coragem, é aposta. Se a esteira não tem rollback testado, o time descobre no pior momento que voltar a versão anterior leva quarenta minutos.
O que medir antes do próximo pico
Três números resolvem a discussão:
- Consultas por requisição nas três páginas mais acessadas.
- Tempo do p95, não o médio — a média esconde exatamente quem está sofrendo.
- Tempo de rollback, cronometrado de verdade, não estimado.
Nenhum dos três exige ferramenta cara. Os três juntos costumam explicar a queda inteira, e nenhum deles é resolvido com uma máquina maior.