Black Friday não cai por falta de servidor

A maioria dos e-commerces que falham na Black Friday não falham por falta de servidor.

É contraintuitivo, porque é no servidor que se concentra a preparação. Escala horizontal, CDN, cache, teste de carga na infraestrutura principal. Tudo isso é necessário, e quase todo mundo faz.

O que quase ninguém prepara com o mesmo cuidado são os pontos que não estão sob o seu controle.

Onde o pico realmente quebra

Os gargalos que mais causam problema sob pico de demanda raramente estão no núcleo da plataforma. Estão nas bordas:

• API de parceiro sem limite de requisição documentado, e sem comportamento definido para quando o limite é atingido. Meio de pagamento, antifraude, cálculo de frete, serviço de endereço.
• Consulta de banco que funciona em condição normal e trava com volume real, porque ninguém testou com dado de produção e com a distribuição real de acesso.
• Integração de estoque síncrona, em que cada consulta de produto bloqueia até ter resposta de um sistema que não foi dimensionado para aquele volume.
• Sessão de usuário escalando para o banco que já está saturado, em vez de ficar numa camada própria.

O padrão se repete: a infraestrutura própria aguenta. O gargalo está em alguma integração que foi tratada como detalhe de implementação, e não como risco operacional.

Por que isso passa despercebido

Porque teste de carga costuma testar o que é da gente.

Simular o pico na plataforma é relativamente simples. Simular o pico no parceiro é difícil: ambiente de homologação que não reproduz produção, contrato que não prevê teste de volume, SLA escrito para média e não para pico.

O resultado é uma preparação que mede a parte mais fácil do sistema e deixa sem teste justamente a parte que vai falhar.

E tem um agravante. Numa plataforma DTC que absorve várias vezes o volume de baseline no pico, uma dependência lenta não derruba só a si mesma. Ela segura conexões, enche filas e contamina o resto do fluxo. O sintoma aparece no checkout; a causa está três integrações atrás.

O que preparação real exige

1. Mapear todas as dependências externas com comportamento sob volume. Não a lista de integrações: o comportamento de cada uma quando a demanda multiplica. Qual o limite? O que acontece quando ele é atingido? Quem é acionado?

2. Testar a carga no fluxo completo. Da busca ao pedido confirmado, passando por cada integração no caminho, e não só na infraestrutura própria.

3. Definir circuit breaker e fallback para cada integração crítica. Se o frete não responde em dois segundos, qual é a resposta padrão? Se o antifraude cai, o pedido espera, segue ou para? Essas decisões precisam ser tomadas em outubro, com calma, e não às dez da noite da sexta-feira.

4. Separar o que é essencial do que é acessório. Recomendação personalizada, avaliação de produto e selo de frete grátis são ótimos. Nenhum deles vale derrubar o checkout. O que pode ser desligado sob pressão deve ter chave para ser desligado.

A pergunta que muda a preparação

A pergunta errada é “nossa infraestrutura aguenta o pico?”. Quase sempre aguenta.

A pergunta certa é “qual integração vai falhar primeiro, e o que acontece com o pedido quando ela falhar?”.

Servidor é o lugar mais fácil de escalar. Não é onde o problema costuma estar.