Como preparar o sistema para pico de acesso e não cair

A campanha foi planejada por meses. O marketing comprou mídia, o comercial negociou estoque, o e-mail saiu à meia-noite em ponto. Dez minutos depois, o site começa a responder devagar, o carrinho trava no pagamento e o atendimento recebe a primeira reclamação. Quando alguém consegue entrar no servidor, o tráfego já passou, e com ele as vendas daquela noite.

O mesmo filme se repete na escola em semana de rematrícula, na clínica que abre a agenda do mês e no evento que libera ingressos. Na escola, o pico também entra na escolha do sistema de gestão escolar, pronto ou sob medida.

A boa notícia é que pico de acesso tem data marcada. Diferente de uma falha aleatória, dá para se preparar com semanas de antecedência. Este texto é o roteiro que usamos para isso: estimar o pico, testar, encontrar os gargalos, preparar a infraestrutura e combinar o que fazer se algo der errado.

Resposta curta: o roteiro em sete passos

A preparação segue esta ordem:

1. Estime o pico com dados do ano anterior e do plano da campanha, em requisições e pedidos por minuto, não em "visitas no dia".
2. Mapeie a jornada crítica: as telas e chamadas que precisam funcionar para a venda (ou a matrícula, ou o agendamento) acontecer.
3. Rode teste de carga em ambiente parecido com produção, acima do pico estimado, várias semanas antes da data.
4. Corrija os gargalos que o teste revelar, quase sempre no banco de dados e nas integrações.
5. Prepare a infraestrutura: escalonamento automático, cache e filas para o que não precisa ser imediato.
6. Congele mudanças perto da data e deixe a observabilidade pronta para enxergar o sistema em tempo real.
7. Monte a sala de guerra com papéis definidos e um plano de contingência escrito para cada falha provável.

Por que sistemas caem justamente no melhor dia

Sistema não cai por excesso de visitantes em abstrato. Cai porque algum recurso finito se esgota, e o resto da cadeia fica esperando por ele. Os suspeitos de sempre:

• Conexões com o banco de dados. O banco aceita um número limitado de conexões simultâneas. Quando as requisições chegam mais rápido do que as consultas terminam, elas se acumulam até o limite, e a partir daí ninguém entra.
• Consultas que eram rápidas com pouco volume. Uma busca sem índice adequado passa despercebida com poucos acessos e vira o centro do problema quando mil pessoas fazem a mesma busca ao mesmo tempo.
• Integrações síncronas. Se o checkout espera a resposta do antifraude, do gateway de pagamento e do cálculo de frete antes de confirmar, o tempo de resposta do sistema passa a ser a soma do tempo de todos eles, e a lentidão de um parceiro vira a sua.
• Bloqueios no mesmo registro. Estoque é o exemplo clássico: muitas vendas tentando baixar o saldo do mesmo produto em promoção, todas esperando a anterior terminar.
• Limites esquecidos. Cota de requisições da API de um fornecedor, limite do provedor de e-mail ou de SMS.

Há ainda um efeito que piora tudo: quando o sistema fica lento, os usuários recarregam a página e clicam de novo no botão de pagar. Cada recarga é uma requisição a mais sobre um sistema que já não dava conta. Por isso a queda costuma ser abrupta, não gradual.

Se o sistema já fica lento em dias normais, comece por aí. O diagnóstico de sistema lento e performance resolve o problema de base; preparar para pico em cima de um sistema que já sofre é empilhar risco.

Estimando o pico: números do ano anterior e campanhas

Preparar sem número é chutar. O objetivo desta etapa é chegar a uma meta concreta de carga para o teste.

O que levantar

• Histórico do pico anterior, no nível de minuto, não de dia. O dia pode ter tido um volume confortável, mas o que derruba o sistema são os minutos logo depois do disparo da campanha.
• Plano da campanha deste ano. Horário dos disparos de e-mail e notificação, mídia paga, influenciadores, abertura de lote. Cada disparo gera uma onda concentrada.
• Crescimento da base. Se a base de clientes ou o catálogo cresceram desde o último pico, o volume esperado cresce junto.
• Mudanças no sistema. O que mudou desde o último pico ainda não foi testado sob pressão.

Como transformar em meta

Um exemplo simples: se no ano passado o minuto mais intenso teve um certo número de pedidos finalizados, e a campanha deste ano tem uma base maior e um disparo mais agressivo, a meta deve ser esse número multiplicado pelo crescimento esperado, com uma margem de segurança por cima. Uma referência prudente é testar para pelo menos o dobro do pico estimado, porque estimativa de campanha costuma errar para baixo.

Converta pedidos em requisições. Uma compra não é uma chamada: é a navegação no catálogo, a busca, o carrinho, o cálculo de frete, o login, o pagamento. Saber quantas requisições cada pedido gera é o que permite montar um teste realista.

Sem histórico, trabalhe com o plano de mídia e o tamanho da base que recebe o disparo, e aumente a margem.

Teste de carga antes da data

Teste de carga é simular, de forma controlada, o volume esperado e observar onde o sistema cede. É a única forma de descobrir o gargalo antes do cliente.

Como fazer um teste que vale alguma coisa

• Ambiente parecido com produção. Testar num servidor menor, com banco vazio, mede outra coisa. O banco precisa ter volume de dados próximo do real, e a infraestrutura, a mesma configuração.
• Roteiro que imita o usuário. O teste deve reproduzir a jornada, com a proporção certa entre quem só navega, quem busca e quem compra, e não apenas bombardear a página inicial.
• Integrações externas simuladas. Não se dispara carga contra o gateway de pagamento ou a transportadora de verdade. Use os ambientes de teste que eles oferecem ou simuladores que respondem com o tempo típico de cada parceiro, incluindo cenários de lentidão.
• Carga crescente, até quebrar. Comece abaixo do esperado e suba em degraus. O resultado mais útil não é "aguentou", é "a partir de tal volume, tal componente começou a falhar".
• Antecedência. Rode o primeiro teste com folga, várias semanas antes da data, para ter tempo de corrigir e testar de novo. Teste na véspera só serve para descobrir que não há tempo.

O que observar durante o teste

Tempo de resposta médio engana. Acompanhe os percentis mais altos (o tempo das requisições mais lentas), a taxa de erros, o uso de conexões do banco, a fila de requisições e o consumo de CPU e memória de cada componente. Sem essa visibilidade, o teste diz que algo quebrou, mas não onde. É o mesmo princípio de observabilidade com logs, métricas e traces: instrumentar antes para diagnosticar em minutos.

Banco de dados e integrações: os gargalos de sempre

Na maioria dos testes de carga, o servidor da aplicação não é o primeiro a cair. O banco de dados e as integrações chegam antes.

No banco de dados

• Índices nas consultas da jornada crítica. Busca de produto, consulta de saldo, histórico do cliente. Cada consulta lenta identificada no teste deve ser analisada uma a uma.
• Pool de conexões dimensionado. Mais conexões não é sempre melhor: acima de certo ponto, o banco gasta mais tempo gerenciando conexões do que executando consultas. O número certo sai do teste.
• Leitura separada da escrita. Réplicas de leitura podem atender catálogo, busca e relatórios, deixando o banco principal livre para gravar pedidos.
• Relatórios pesados fora do horário do disparo da campanha.
• Estoque sem fila de bloqueio. Para produtos muito disputados, vale reservar saldo de forma atômica e curta, em vez de manter uma transação longa aberta durante todo o checkout.

Nas integrações

O pico é o momento em que o desenho da integração entre ERP e e-commerce é posto à prova. Três cuidados:

• Tempo limite em toda chamada externa. Nenhuma requisição deve esperar indefinidamente por um parceiro.
• Disjuntor (circuit breaker). Se o serviço de frete começa a falhar, o sistema para de chamá-lo por alguns instantes e usa uma alternativa (uma tabela de frete de contingência, por exemplo), em vez de derrubar o checkout inteiro.
• Confirme os limites dos parceiros. Pergunte ao gateway, à plataforma de loja e ao ERP quais são as cotas de requisição e se há procedimento especial para datas de pico.

Escalonamento automático e cache

Com os gargalos corrigidos, a infraestrutura precisa acompanhar o volume.

Escalonamento automático

Em nuvem, a aplicação pode subir novas instâncias quando a carga aumenta e desligá-las quando cai. Funciona bem para a camada da aplicação, desde que ela não guarde estado no próprio servidor (sessão de usuário, arquivos temporários). Plataformas como a Vercel fazem isso no front, como mostramos em Vercel ou AWS. Três ajustes fazem diferença:

• Pré-aquecimento. Uma instância nova leva algum tempo para ficar pronta. Para um disparo com hora marcada, suba a capacidade antes do horário, sem esperar o tráfego chegar.
• Limites máximos conscientes. Escalar a aplicação para muitas instâncias pode simplesmente mover o problema para o banco, que recebe conexões de todas elas.
• Banco não escala no mesmo ritmo. Aumentar a capacidade do banco costuma levar tempo ou exigir janela de manutenção. Dimensione antes da data, não durante.

Cache

O que é igual para todos os usuários não precisa ser calculado a cada visita. Páginas de catálogo, imagens, vitrine, regras de promoção: tudo isso pode ser servido de cache ou de uma rede de distribuição de conteúdo. Quanto mais requisições param no cache, menos chegam ao banco. O cuidado é com dados que mudam rápido, como preço e estoque, que precisam de tempo de validade curto ou de invalidação quando mudam.

Filas para não perder pedidos

Nem tudo precisa acontecer no momento do clique. Uma fila separa o que o usuário precisa ver agora do que pode ser processado logo em seguida.

Com fila, o pico vira uma onda que o sistema absorve no seu ritmo. Se o ERP desacelera, os pedidos esperam na fila em vez de se perderem ou travarem o checkout. Duas regras tornam isso seguro: o processamento de cada mensagem precisa ter efeito uma única vez (idempotência), mesmo se ela for reenviada, e precisa existir um lugar visível para as mensagens que falharam, com reprocessamento.

Para picos extremos, como venda de ingressos, existe a sala de espera virtual: o usuário entra numa fila com posição visível e é liberado aos poucos, melhor do que um sistema que cai para todos.

Sala de guerra e plano de contingência

Mesmo com tudo testado, o dia do pico pede gente preparada e decisões tomadas antes.

Congelamento de mudanças

Defina um período antes da data em que nada entra em produção, exceto correção crítica aprovada.

Sala de guerra

• Quem está de plantão, em que horário, com qual telefone.
• Quem decide: uma pessoa com autoridade para acionar a contingência sem precisar consultar três diretores.
• Painel único com os indicadores da jornada crítica: pedidos por minuto, erros, tempo de resposta, fila, banco.
• Contato direto dos parceiros críticos: hospedagem, gateway, plataforma, ERP.
• Canal com atendimento e marketing para avisar o cliente rápido.

Plano de contingência

Para cada falha provável, uma ação escrita:

• Gateway principal fora: ativar o meio de pagamento secundário.
• Frete fora: usar tabela de contingência.
• Banco no limite: desligar funcionalidades não essenciais (recomendações, avaliações, busca avançada) para aliviar a carga.
• Volume acima do suportado: ativar a sala de espera ou adiar um disparo de campanha.
• Versão com defeito: procedimento de volta para a versão anterior, já ensaiado.

Checklist das semanas anteriores

• Pico estimado em pedidos e requisições por minuto.
• Jornada crítica mapeada.
• Teste de carga realizado acima do pico, com gargalos corrigidos e reteste feito.
• Banco dimensionado e consultas críticas revisadas.
• Tempos limite e disjuntores nas integrações.
• Limites dos parceiros confirmados por escrito.
• Escalonamento configurado e capacidade pré-aquecida para os horários de disparo.
• Cache ativo nas páginas de catálogo.
• Filas para ERP, nota, notificações e CRM.
• Congelamento de mudanças com data definida.
• Escala de plantão, painel e contatos prontos.
• Plano de contingência escrito e ensaiado.

Depois do pico, faça uma revisão sem caça a culpados: o que funcionou, o que quase falhou e o que muda para a próxima data. Os números desse dia são o histórico do próximo ano.

Perguntas frequentes

Com quanto tempo de antecedência preparar o sistema para a Black Friday?

Com várias semanas de antecedência. O primeiro teste de carga deve acontecer com folga suficiente para corrigir os gargalos e testar de novo antes da data, e o congelamento de mudanças entra perto do pico. O prazo exato da preparação para a Black Friday depende do estado atual do sistema e do que o teste revelar.

O que é teste de carga?

Teste de carga é a simulação controlada do volume de acessos esperado, em ambiente parecido com produção, para descobrir onde o sistema cede antes que o cliente descubra. O teste reproduz a jornada real do usuário, aumenta a carga em degraus e mostra a partir de que volume cada componente começa a falhar.

Colocar mais servidores resolve o pico de acesso?

Nem sempre. Escalar a aplicação em nuvem ajuda, mas pode apenas mover o problema para o banco de dados, que recebe conexões de todas as instâncias e não escala no mesmo ritmo. Em pico de acesso, os gargalos mais comuns estão no banco e nas integrações, e só o teste de carga mostra onde estão.

O que é sala de espera virtual?

Sala de espera virtual é uma fila de acesso em que o usuário recebe uma posição visível e entra no site aos poucos, conforme o sistema consegue atender. Ela é usada em picos extremos, como venda de ingressos, porque é melhor organizar a entrada do que deixar o sistema cair para todos ao mesmo tempo.

Como a Pervian Tech trabalha preparação para picos

Na Pervian Tech, preparar um sistema para pico faz parte do nosso trabalho de cloud e DevOps. Começamos pelo diagnóstico: como o sistema se comportou na última data importante, qual é a jornada crítica, onde estão o banco, as integrações e os limites dos parceiros. A partir daí montamos o teste de carga, corrigimos os gargalos que ele revelar, configuramos escalonamento, cache e filas e deixamos a sala de guerra pronta, com painel e plano de contingência.

O prazo depende do estado atual do sistema e da distância até a data, e por isso é definido depois do diagnóstico inicial, que é gratuito. Cada operação é diferente, então o trabalho é sob medida e o investimento é sob consulta. Se a sua próxima data de pico já está no calendário, conte como o sistema se comportou na última.