O cenário que todo gestor de e-commerce conhece: é 00h01 da Black Friday, a campanha está no ar, o tráfego explodiu, e o site travou.
Não caiu completamente. Só ficou lento o suficiente para o cliente desistir.
Estudos de performance web mostram consistentemente que cada segundo adicional de carregamento reduz conversão em duplo dígito percentual.
Na Black Friday, com tráfego 5x a 10x acima do normal, esse efeito se multiplica.
O problema: a maioria dos e-commerces descobre os gargalos no momento errado, quando o pico já chegou.
As correções que poderiam ter sido feitas em outubro viram apagão em novembro.
O erro de diagnóstico
Quando o site fica lento, o reflexo imediato é culpar a hospedagem. Precisa de mais servidor. Às vezes é verdade. Com frequência, não é.
Lentidão em pico de tráfego tem causas em camadas. Adicionar capacidade de servidor resolve apenas uma delas e às vezes nem isso, se o gargalo está em outro lugar.
As quatro camadas onde lentidão pode originar:
Infraestrutura: capacidade de processamento, memória, rede. Aqui escalar ajuda.
- Aplicação: código ineficiente, consultas desnecessárias, ausência de cache. Aqui escalar não resolve só adia o colapso.
- Banco de dados: queries lentas, ausência de índices, conexões esgotadas. Aqui escalar pode piorar mais tráfego chega ao mesmo gargalo mais rápido.
- Integrações externas: APIs de pagamento, antifraude, ERP, transportadoras. Aqui o problema nem é seu, mas o cliente culpa você.
- O diagnóstico correto exige identificar em qual camada o gargalo está antes de qualquer ação. Equipes que pulam para solução sem diagnóstico frequentemente resolvem o problema errado.
As causas reais
Cache mal configurado ou ausente
Cache é a diferença entre o servidor processar uma requisição e simplesmente devolver uma resposta já pronta.
Em tráfego normal, cache mal configurado é ineficiência. Em pico de Black Friday, é colapso.
O que acontece sem cache adequado: Cada visitante que acessa a página de um produto dispara uma consulta ao banco de dados.
Com 100 visitantes simultâneos na mesma página, são 100 consultas idênticas. Com 10.000 visitantes, o banco quebra.
Os erros mais comuns de configuração de cache: Cache de página inteira desativado para usuários não logados o caso mais frequente e mais fácil de corrigir.
Páginas de produto e categoria para visitantes anônimos são candidatos óbvios para cache agressivo.
TTL (tempo de vida do cache) muito curto cache que expira a cada 30 segundos em um produto que não mudou em dias não serve para nada em pico de tráfego.
Cache invalidado desnecessariamente sistemas que limpam todo o cache ao menor sinal de mudança no catálogo forçam o servidor a reprocessar tudo do zero. Invalidação seletiva (só o que mudou) é o correto.
Ausência de cache de objetos resultados de consultas frequentes ao banco (categorias, menu de navegação, configurações da loja) precisam viver em memória, não ser recalculados a cada requisição.
Ferramentas relevantes: Redis e Memcached para cache de objetos em memória. CDN para cache de assets estáticos e páginas. Varnish para cache reverso de página inteira.
A regra prática: qualquer dado que não muda entre uma requisição e outra não deveria ser recalculado. Se está sendo, é oportunidade de cache.
Banco de dados como gargalo silencioso
O banco de dados é frequentemente o gargalo que ninguém vê até o momento em que ele afunda a operação inteira.
Por que o banco sofre mais do que o resto: Diferente do servidor de aplicação, que pode ser escalado horizontalmente adicionando mais instâncias, bancos de dados relacionais tradicionais têm limitações reais de escala vertical e custo alto de escala horizontal.
O banco que suporta 200 conexões simultâneas em produção normal pode esgotar esse limite em minutos durante um pico.
Os problemas mais comuns: Queries sem índice adequado uma consulta que percorre uma tabela de 2 milhões de produtos sem índice pode levar segundos. Em tráfego normal passa despercebida. Em pico, trava fila de conexões.
N+1 queries código que faz uma consulta para listar produtos e depois uma consulta separada para cada produto buscar suas imagens, atributos ou avaliações. Em 50 produtos por página, são 51 consultas onde deveria haver uma.
Pool de conexões mal dimensionado cada requisição da aplicação abre uma conexão com o banco.
Se o pool tem limite baixo, requisições ficam em fila esperando conexão disponível. O usuário vê o site travado.
Falta de read replicas todo o tráfego de leitura (que é 95% das operações em um e-commerce) indo para o mesmo banco que processa escritas (pedidos, atualizações de estoque) é disputa desnecessária por recurso.
O que fazer antes: rodar EXPLAIN nas queries mais frequentes, identificar as lentas, adicionar índices onde faltam e revisar o pool de conexões com base na projeção de tráfego esperado.
Integrações síncronas no caminho crítico
Este é o gargalo que mais surpreende gestores técnicos experientes: o site da loja está funcionando, mas o checkout trava porque um serviço externo está lento.
O que são integrações no caminho crítico: Qualquer serviço externo que precisa responder para que o usuário possa avançar. Antifraude, gateway de pagamento, consulta de CEP, cálculo de frete em tempo real, verificação de estoque em ERP externo.
Se esse serviço demora 3 segundos para responder, o usuário espera 3 segundos. Se ele timeout, o checkout quebra.
O problema de Black Friday: Esses serviços externos também recebem pico de Black Friday. Não só o seu e-commerce todos os clientes deles ao mesmo tempo. Latência aumenta. Timeouts aumentam.
O que fazer: Circuit breaker se um serviço externo começa a responder com latência alta ou erros, o sistema para de chamá-lo temporariamente e usa um fallback (valor de frete estimado, aprovação condicional). Evita que a lentidão de um serviço externo paralise o checkout.
Timeout configurado explicitamente toda integração precisa ter timeout definido. Sem timeout, uma requisição pode ficar pendurada indefinidamente, segurando recurso do servidor.
Filas assíncronas onde possível operações que não precisam de resposta imediata (notificação de pedido ao ERP, disparo de e-mail de confirmação) não deveriam estar no caminho síncrono do checkout.
Arquivos estáticos sem CDN
Imagens de produto, CSS, JavaScript, fontes tudo isso servido diretamente do servidor da aplicação é desperdício de capacidade computacional e latência desnecessária para o usuário.
O impacto em Black Friday: Uma página de categoria com 40 produtos, cada um com 2 imagens, são 80 requisições de imagem.
Sem CDN, todas vão para o servidor de aplicação, disputando recursos com as requisições que realmente precisam de processamento.
Com CDN, essas 80 requisições são respondidas pelo nó geograficamente mais próximo do usuário, sem tocar no servidor da aplicação.
Além das imagens: JavaScript de terceiros (analytics, chat, pixel de conversão) carregado de forma síncrona bloqueia renderização da página.
Em mobile com conexão instável o caso de boa parte do tráfego de Black Friday no Brasil o impacto é severo.
Falta de teste de carga
Nenhuma das otimizações anteriores tem valor real se não foram validadas sob condições próximas do pico esperado.
O que é teste de carga e o que não é: Teste de carga não é abrir o site em vários computadores ao mesmo tempo.
É simular tráfego realista com a distribuição correta de páginas acessadas, a proporção de usuários que chegam ao checkout, o tempo médio em cada página e observar onde o sistema começa a degradar.
O que o teste revela: O ponto de inflexão quantos usuários simultâneos o sistema atual suporta antes de a latência aumentar significativamente.
O gargalo primário banco de dados, aplicação ou infraestrutura?
O comportamento sob falha quando o sistema começa a degradar, ele degrada graciosamente (fica lento mas funciona) ou colapsa?
Quando fazer: Mínimo quatro semanas antes do evento. Resultado do teste precisa de tempo para gerar ação corretiva, que por sua vez precisa de tempo para ser testada novamente.
Fazer teste de carga na semana da Black Friday é documentar o problema, não o resolver.
O checklist de preparação
Com 8+ semanas de antecedência
- Rodar teste de carga baseline para entender o estado atual
- Auditar as queries mais lentas do banco de dados (EXPLAIN + slow query log)
- Mapear todas as integrações no caminho crítico do checkout
- Revisar configuração de cache por tipo de página
Com 4–8 semanas
- Implementar correções de cache identificadas na auditoria
- Adicionar índices nas queries problemáticas
- Configurar circuit breakers nas integrações externas críticas
- Migrar assets estáticos para CDN se ainda não estiver feito
- Revisar pool de conexões do banco com base na projeção de tráfego
Com 2–4 semanas
- Rodar teste de carga com o tráfego projetado para Black Friday
- Validar que as correções implementadas moveram o ponto de inflexão
- Testar comportamento de fallback das integrações externas
- Fazer simulação de degradação parcial (o que acontece se o antifraude ficar lento?)
Com menos de 2 semanas
- Sem mudanças estruturais risco de introduzir bug novo supera benefício
- Garantir plano de rollback para qualquer mudança recente
- Definir protocolo de resposta a incidente com o time técnico
- Configurar monitoramento e alertas com thresholds ajustados para o evento
O que monitorar
Preparação sem monitoramento é voar às cegas. Durante o evento, o time técnico precisa saber antes do cliente que algo está degradando.
Métricas que precisam estar em dashboard visível durante a Black Friday:
- Latência do checkout (p95 e p99, não só média)
- Taxa de erro por endpoint
- Utilização de conexões do banco de dados
- Hit rate do cache (percentual de requisições respondidas pelo cache vs. processadas)
- Tempo de resposta das integrações externas (antifraude, gateway, transportadora)
- Fila de processamento de pedidos
Alerta configurado em threshold, não em colapso. O objetivo é saber quando o sistema está chegando no limite não quando já passou.
Para fechar
Lentidão na Black Friday raramente é surpresa é consequência de problemas conhecidos que não foram priorizados.
A boa notícia é que a maioria dos gargalos é identificável e corrigível com antecedência suficiente.
O que separa as lojas que passam pela Black Friday sem incidente das que entram em modo de crise não é tamanho nem orçamento.
É diagnóstico correto feito com tempo suficiente para agir.
A Dupla faz auditoria de performance em e-commerces e implementa as correções necessárias antes dos picos de tráfego. Se a Black Friday está no horizonte e você não tem certeza de que a sua infraestrutura aguenta, fale com a gente antes que o problema apareça.