Checklist Black Friday: 18 verificações técnicas para sua loja virtual

Black Friday no Brasil concentra entre 8% e 14% do faturamento anual de uma loja média em uma única semana. Em 2024, o varejo online brasileiro movimentou cerca de R$ 9,3 bilhões no período Black Friday/Cyber Monday.^[1] Caiu 30 minutos no horário de pico? Já perdeu o equivalente a um dia inteiro de tráfego orgânico.

Este checklist técnico é a versão pragmática do que você precisa preparar — 18 itens organizados em 4 frentes, com prazo realista.

Cronograma sugerido

1. Infraestrutura (8–6 semanas antes)

1 — Dimensione com base no pico real, não na média

Pegue o pico de RPS (requisições por segundo) de Black Fridays passadas e multiplique por 1.5–2x. Se é seu primeiro ano, parta de 3× a média do horário comercial. Banco é o gargalo número um: aumente CPU/RAM antes de aumentar workers da aplicação.

2 — Banco com slow query log e pool dimensionado

Ative slow query log com long_query_time=0.5 dois meses antes — você terá tempo para corrigir. Aumente max_connections para 2× o pico esperado de workers, mas não mais — conexões idle também consomem RAM.

3 — Cache em borda (Cloudflare/Fastly) com regras claras

Defina o que é cacheado em borda (home, categoria, produto) e o que não é (carrinho, checkout, conta). Em Magento 2, garanta que o Varnish está configurado corretamente e teste o "cache hit ratio" — deve estar acima de 90% sob tráfego normal.

4 — CDN para estático: imagem, JS, CSS

Imagem servida do servidor de origem em pico é a forma mais rápida de derrubar a banda contratada. Use uma CDN dedicada (Cloudflare, Akamai, AWS CloudFront) e habilite WebP.

5 — DNS com TTL curto na véspera (mas não muito)

Reduza TTL de DNS para 5 minutos uma semana antes — caso precise mudar IP em emergência, o cache de DNS não te trava. Logo após o evento, volte para o TTL normal.

2. Aplicação e integrações (5–3 semanas antes)

6 — Gateway de pagamento com plano B

Tenha um segundo gateway configurado e testado, mesmo que offline. Pague o setup e deixe-o em standby.

7 — Antifraude assíncrono (não bloqueia checkout)

Antifraude síncrono é uma péssima ideia em pico. Configure o pedido para entrar emfraud_review e o antifraude libera depois, em segundos. Se ele cair, pedidos continuam entrando.

8 — Cálculo de frete em cache

Cálculo de frete pelo Correios/transportadora em tempo real é o gargalo escondido do checkout. Configure cache de cotação por CEP + peso (24h é razoável) ou pelo menos timeout curto (3s) com fallback de tabela.

9 — Fila de pedidos preparada para o pico

Em Magento 2, escale consumers do queue. Em WooCommerce, dimensione Action Scheduler. Falha de fila não derruba a loja, mas trava pedidos em silêncio — o cliente vê "pedido confirmado" e nada acontece depois. Veja como detectar pedidos travados antes do SAC explodir.

10 — Cupom com limite de uso e validação de concorrência

Cupom com uso ilimitado em pico é receita para overbooking. Defina limite global e por cliente; teste o que acontece quando 1000 pessoas tentam usar simultaneamente. Em Magento 2, a validação de cupom usa lock — má configuração trava o checkout inteiro.

11 — Estoque atualizado com fonte única de verdade

Estoque desatualizado é o vilão da Black Friday — você vende o que não tem e o cliente recebe "produto cancelado" depois. Garanta que o ERP é a fonte e a loja é só uma projeção, com sincronização em minutos, não horas. Use o teste de SKUs visíveis sem estoque para alertar sobre divergência.

3. Ensaio e monitoramento (2 semanas antes)

12 — Teste de carga sintético

Use k6, Locust ou Gatling para simular o pico esperado. Foque no funil de conversão — navegação não importa tanto quanto checkout. Identifique o ponto de quebra: a partir de qual RPS o p95 ultrapassa 3s.

13 — Monitoramento de checkout end-to-end

Configure um teste sintético que percorra: home → categoria → produto → carrinho → checkout com CEP → confirmação. Rode a cada 5 minutos. Se algum passo falhar, é alerta crítico imediato.

14 — Alertas em canais que a equipe lê

E-mail não é canal de alerta crítico em Black Friday. Use Discord, Slack ou Telegram — onde a equipe já está. Configure pager rotation se for um time grande. Veja os 7 alertas essenciais.

15 — Painel público de status

Quando algo cai, dezenas de clientes perguntam ao SAC. Ter uma página de status pública (com slug do seu domínio) economiza horas de atendimento e demonstra transparência.

4. Véspera e dia D (1 semana antes)

16 — Freeze total de mudanças

Sem novos deploys, sem atualização de extensão, sem mudança de tema, sem integração nova. A semana é só de monitoramento. Hotfix crítico passa, com revisão dupla.

17 — Plano de incidente escrito e ensaiado

Quem aciona quem? Em qual canal? Quem decide rollback? Quem fala com o cliente? Um documento de uma página, atualizado e enviado para todo mundo, vale ouro às 23h da Black Night.

18 — Backup verificado, rollback testado

Backup de banco rodando todo dia é o mínimo. Restore testado é o que importa — quando você precisa de fato, é tarde demais para descobrir que o backup está corrompido. Faça pelo menos um restore completo na última semana, em ambiente isolado.

Depois do evento: o que medir

Termine a semana com três números: faturamento, ticket médio e tempo total fora do ar. O terceiro é o que define se o ano que vem precisa de outra rodada de investimento ou se você pode operar como está.