Black Friday: como preparar a infraestrutura de TI para o pico de 2026
Em 28 de novembro de 2025 o e-commerce brasileiro fechou 8,69 milhões de pedidos em 24 horas. O volume de pedidos subiu 28% contra o ano anterior, enquanto o faturamento cresceu 11,2%, segundo o balanço medido pela Confi Neotrust.
A distância entre essas duas curvas é o número que interessa a quem responde pela infraestrutura. Mais pedidos com ticket médio menor significa mais transações por real faturado. São mais chamadas ao gateway, mais escrita no banco de dados e mais sessões simultâneas. A carga cresce mais rápido que a receita que a financia.
Por isso, este guia organiza a preparação em cinco janelas, de D-60 até o dia seguinte ao evento. Cada uma traz o entregável da janela, o limiar que muda a decisão e o erro que costuma aparecer tarde demais.
O que muda na infraestrutura durante a Black Friday
Na Black Friday, a infraestrutura enfrenta um perfil de carga que não se repete no resto do ano. São dois picos em menos de 24 horas: o primeiro na virada da meia-noite, o segundo no fim da tarde de sexta. O tráfego não sobe de forma linear. Ele salta, sustenta por horas e cai, sem deixar tempo para provisionamento reativo.
O componente que satura primeiro quase nunca é aquele que a equipe vigia com mais atenção. Servidor de aplicação escala horizontalmente com facilidade. Em contrapartida, o pool de conexões do banco, a fila do adquirente e o índice de busca do catálogo não acompanham o mesmo ritmo.
| Camada | Sinal que aparece primeiro | Por que o alerta clássico chega tarde |
|---|---|---|
| Banco de dados | Tempo de espera por conexão livre no pool e active_connections encostado no teto |
A fila se forma antes de a CPU subir. Alerta por consumo de CPU dispara depois do impacto no checkout |
| Gateway de pagamento | Latência de autorização por adquirente e taxa de recusa fora da linha de base | O erro nasce fora do seu ambiente. Nenhuma métrica de servidor registra a degradação da bandeira |
| Busca e catálogo | Tempo de resposta do índice sob concorrência alta e atraso na fila de reindexação | O serviço responde HTTP 200 com resultado vazio. Health check simples continua verde |
| Sessão e carrinho | Taxa de evicção no cache distribuído e miss ratio acima do histórico |
O carrinho esvazia sozinho. A reclamação chega pelo SAC muito antes de virar incidente |
| CDN e origem | Queda do hit ratio com salto de requisições que chegam à origem |
Uma purga de cache mal dimensionada converte pico de tráfego em pico de origem em segundos |
Cada décimo de segundo tem preço mensurável. No estudo conduzido pela Deloitte a pedido do Google, uma melhora de 0,1 segundo no carregamento mobile elevou a conversão de varejo em 8,4%. O ticket médio subiu 9,2% sobre as 37 marcas analisadas.
Na Marisa, monitoramos as 433 lojas a partir do datacenter, junto com o e-commerce, o app mobile e o gateway de pagamento. O mesmo painel acompanha o servidor de cada loja, os bancos Oracle e o sistema de transferência eletrônica de fundos.
No pico, loja física e canal digital disputam o mesmo backend. Foi por isso que esse projeto de varejo multi-loja colocou os dois no mesmo painel desde o início. Tratar o digital como ambiente separado esconde justamente essa disputa.
Passo 1: linha de base e projeção de capacidade (D-60)
Sem linha de base não existe dimensionamento. Antes de discutir quanto provisionar, a equipe precisa saber qual é o pico normal de um dia útil comum. A medição sai dos componentes que vão saturar, não dos que já têm painel pronto.
Colete pelo menos 30 dias de série temporal na borda, no banco de dados e no pool de conexões. Some a esses três o volume de autorizações por minuto no gateway e o consumo por serviço. O planejamento de capacidade parte desses números, nunca do palpite do fornecedor.
Em seguida, a projeção aplica o multiplicador do ano anterior sobre a linha de base atual. Se o pico de 2025 ficou em nove vezes a média de um dia útil, comece por aí e some o crescimento orgânico do canal. Reserve folga para o dobro do previsto nas camadas que não escalam em minutos.
O erro que aparece nesta janela
Dimensionar pela média do dia em vez do pico de cinco minutos. A média dilui a virada da meia-noite, que é justamente onde a fila se forma e onde o timeout começa a cascatear. Por isso, trabalhe com o percentil 99 da janela de cinco minutos como referência de projeto.
Passo 2: teste de carga no caminho de compra (D-45)
Teste de carga que bate na página inicial não prova quase nada. A home é cacheável, estática na maior parte e resolvida pela CDN antes de tocar a origem. O que derruba a operação é o caminho que escreve: busca, página de produto, carrinho, checkout, autorização de pagamento e confirmação de pedido.
Monte o cenário com a proporção real do funil, não com distribuição uniforme entre as etapas. Um teste com quase todo o tráfego preso à navegação gera um perfil de escrita muito diferente. Metade das sessões chegando ao checkout produz outro cenário, bem mais pesado. Use a conversão do ano anterior como referência de mistura.
Em seguida, execute no ambiente que vai para produção, com o mesmo volume de catálogo e o mesmo conjunto de dados. Um índice de busca com 2 mil SKUs responde de um jeito; com 200 mil, responde de outro. Repita o ciclo até que o gargalo encontrado seja aceitável, não até que o teste passe.
Em contrapartida, teste de carga isolado não substitui observação contínua. O monitoramento de e-commerce precisa estar de pé antes do ensaio, porque é ele que mostra onde o sistema cedeu enquanto a carga subia.
Passo 3: instrumentação do funil e das integrações (D-30)
Nesta janela o objetivo muda. Sai o dimensionamento e entra a visibilidade. A pergunta que a operação responde no dia é qual etapa parou, não se o servidor continua de pé.
Antes de tudo, instrumente cada etapa do funil como indicador de negócio: sessões, adições ao carrinho, checkouts iniciados, pagamentos autorizados e pedidos confirmados. Quando a curva de pedidos cai enquanto a de sessões continua subindo, o problema mora entre as duas etapas. O painel aponta em qual delas.
Os meios de pagamento merecem trilha própria. Acompanhe latência e taxa de recusa separadas por adquirente e por bandeira. Uma bandeira degradada leva embora parte da receita sem mexer em nenhuma métrica de infraestrutura.
Por fim, complete a cobertura com robôs que executam a compra ponta a ponta, de fora da sua rede, a cada poucos minutos. É o único sinal que responde se o cliente consegue comprar agora, independente do que os gráficos internos mostram.
Passo 4: congelamento de mudanças e plano de reversão (D-15)
O congelamento existe para proteger o ambiente que passou no teste de carga. A partir de D-15, nenhuma alteração de código, de esquema de banco, de regra de firewall ou de configuração de CDN entra sem aprovação formal. O ambiente homologado é o ambiente que vai ao ar.
Nem tudo entra no congelamento. A lista de exceções precisa estar escrita antes do evento, não negociada durante ele. Correção de vulnerabilidade crítica, ajuste de limite de recurso e troca de conteúdo da campanha seguem permitidos, desde que passem pelo mesmo comitê.
Além disso, toda mudança liberada carrega plano de reversão testado, com tempo estimado e responsável nomeado. Reversão que existe apenas no documento equivale a não ter reversão. Esse controle faz parte da governança de TI aplicada ao evento, que precisa coordenar TI, marketing, logística e lojas físicas em torno do mesmo calendário.
Passo 5: war room, acionamento e o dia seguinte (D-1 a D+1)
A sala não se justifica pelo tamanho do evento. Ela se justifica pelo critério de entrada, definido antes. Três gatilhos abrem o war room. São eles: queda sustentada de pedidos por mais de dez minutos, indisponibilidade de etapa do checkout ou degradação do adquirente principal.
Em seguida, registre a regra de acionamento com nome e canal, nunca com lista de e-mails. Cada gatilho aponta para um responsável de plantão, com tempo de resposta acordado e um segundo nível automático quando o primeiro não confirma. A escalação de alertas precisa ser testada com disparo real antes do evento.
Ao mesmo tempo, reduza o ruído de propósito nessa janela. Suba os limiares de alertas informativos, silencie o que não gera ação imediata e deixe no plantão apenas o que representa perda de venda. Fadiga de alerta na madrugada de sexta consome o tempo que a equipe não tem para gastar. A conta do outro lado também é concreta.
A parada não planejada tem preço tabelado. Segundo o levantamento de 2026 da Splunk com a Oxford Economics, cada minuto custa em média US$ 15 mil ao Global 2000.
Depois que a curva cai, colete o material enquanto a memória está fresca. Registre o pico real por camada, a distância entre previsto e observado e o tempo até alguém perceber. Esse registro vira a linha de base do ano seguinte.
Gravamos há alguns anos onze recomendações para evitar indisponibilidade nessa data. A parte de arquitetura envelheceu desde então, porém o roteiro de operação continua de pé.
99,9% de uptime não acontece por acidente. É resultado de engenharia.
Estruturamos arquiteturas de monitoramento proativo que elevam sua disponibilidade de forma gradativa e mensurável, com SLA garantido em contrato.
O que a segunda-feira revela
A Black Friday raramente cria problemas novos. Na verdade, ela expõe em poucas horas os limites que já existiam no ambiente e que o tráfego de um dia comum nunca alcançou. O pool subdimensionado, a integração sem timeout, o alerta que ninguém validou: tudo isso já estava lá em outubro.
Por isso a preparação vale mais pelo que deixa depois do evento do que pelo evento em si. A linha de base medida, o teste de carga automatizado, o funil instrumentado e a regra de acionamento testada continuam úteis em janeiro. O próximo pico chega sem data marcada no calendário.
Em suma, o trabalho de D-60 a D+1 não é um projeto sazonal. Ele é a primeira versão disciplinada da operação que a empresa deveria ter o ano inteiro. Se a sua equipe vai encarar o próximo pico com a visibilidade que tem hoje, vale conversar antes. Fale com um especialista da OpServices para desenhar a cobertura do seu canal de vendas.

