# Como preparar o sistema para pico de acesso e não cair > Black Friday, rematrícula ou venda de ingressos: o roteiro para preparar o sistema para pico de acesso, do teste de carga ao plano de contingência. Fonte: https://pervian.tech/blog/preparar-sistema-para-pico-de-acesso · Pervian Tech · publicado em 2026-10-01 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](https://pervian.tech/blog/matricula-online-para-escolas), na clínica que [abre a agenda do mês](https://pervian.tech/blog/sistema-de-agendamento-online) 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](https://pervian.tech/blog/sistema-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](https://pervian.tech/blog/integracao-com-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](https://pervian.tech/blog/sistema-lento-diagnostico-de-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](https://pervian.tech/blog/observabilidade-logs-metricas-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](https://pervian.tech/blog/integracao-erp-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](https://pervian.tech/blog/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](https://pervian.tech/blog/filas-e-mensageria-quando-usar) separa o que o usuário precisa ver agora do que pode ser processado logo em seguida. | Etapa | Precisa ser imediata? | Pode ir para fila? | |---|---|---| | Confirmar o pedido e reservar estoque | Sim | Não | | Autorizar o pagamento | Em geral, sim | Depende do meio e do gateway | | Enviar o pedido para o ERP | Não | Sim | | Emitir a nota fiscal | Não | Sim | | Enviar e-mail e notificação de confirmação | Não | Sim | | Atualizar CRM e ferramentas de marketing | Não | Sim | 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](https://pervian.tech/servicos/cloud-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](https://pervian.tech/#contato).