Picos de acesso revelam comportamentos que não aparecem em testes leves. A aplicação pode suportar tranquilamente o tráfego médio de um dia comum e, ainda assim, falhar quando a concorrência aumenta rapidamente, quando milhares de transações disputam o mesmo recurso ao mesmo tempo, ou quando uma dependência externa (gateway de pagamento, API de terceiros, serviço de autenticação) ultrapassa seu próprio limite e arrasta o restante da cadeia junto.

Por que exatamente no pico?

Na maioria dos casos, a infraestrutura foi dimensionada para o tráfego médio, não para o pico — que costuma ser de 5 a 20 vezes maior que um dia normal. Enquanto o volume está dentro da curva esperada, tudo funciona; no instante em que a demanda sobe de forma abrupta, os limites que estavam invisíveis (número de conexões, threads disponíveis, memória, cota de uma API externa) aparecem todos ao mesmo tempo. O sistema não quebra por estar mal construído — ele quebra porque nunca foi testado no cenário que efetivamente importa: o de maior movimento.

Os padrões de falha mais comuns

Ainda que cada aplicação tenha suas particularidades, a grande maioria das quedas em pico segue um número pequeno de padrões recorrentes:

  • Esgotamento do pool de conexões do banco: sob alta concorrência, as conexões disponíveis se esgotam e consultas que levavam 50 ms passam a levar segundos, travando toda a fila de requisições atrás delas.
  • Esgotamento de threads/workers da aplicação: cada requisição ativa ocupa um worker; quando todos estão ocupados, novos usuários ficam na fila ou recebem erro imediatamente.
  • Consumo de memória fora de controle: o volume simultâneo de sessões e objetos em memória cresce mais rápido do que o esperado, derrubando o processo ou disparando o OOM killer.
  • Dependências de terceiros como gargalo: se o gateway de pagamento, o serviço de frete ou o widget de chat ficar lento, e não houver timeout e fallback configurados, essa lentidão se propaga para toda a aplicação — um efeito em cascata conhecido como cascading failure.
  • Tempestade de sessões (thundering herd): quando milhares de sessões ou caches expiram ao mesmo tempo, todas as requisições batem simultaneamente no banco ou na origem, multiplicando a carga exatamente no pior momento.

Load, stress, spike e soak: quatro testes, quatro perguntas diferentes

Não existe um teste único que responda a todas as perguntas de performance — por isso uma estratégia sólida combina tipos diferentes de teste, cada um simulando um cenário de risco distinto:

  • Teste de carga (load test): aplica o volume esperado de forma gradual e constante para validar se o sistema atende ao tráfego normal (e ao pico projetado) dentro dos limites de latência aceitáveis.
  • Teste de estresse (stress test): aumenta a carga continuamente, além do esperado, até encontrar o ponto de ruptura — revelando onde e como o sistema falha, e quão bem ele se recupera depois.
  • Teste de pico (spike test): simula um salto brusco de tráfego — por exemplo, de centenas para milhares de usuários em poucos minutos — para verificar se a aplicação absorve, enfileira ou rejeita esse excesso de forma controlada, sem cair.
  • Teste de resistência (soak test): mantém uma carga constante por horas (ou dias) para expor vazamentos de memória, esgotamento gradual de conexões e degradação que só aparece com o tempo — problemas que um teste curto nunca revelaria.

Testar antes de uma rematrícula, Black Friday ou lançamento de produto reduz drasticamente o risco de descobrir o limite real do sistema em produção, na frente do usuário.

Perguntas executivas para levar à equipe técnica

Para quem responde pelo negócio, o valor de conhecer os tipos de teste não está em executá-los, mas em saber pedir o certo. Carlos Eduardo Vazquez, no livro Teste de Desempenho para Executivos e CTOs, propõe traduzir cada tipo de teste em uma pergunta de risco que qualquer liderança — técnica ou não — pode levar para a reunião com a engenharia antes de aprovar um orçamento, um lançamento ou uma expansão:

  • Teste de carga: "Estamos operando de forma confiável dentro do que já chamamos de normal?"
  • Teste de estresse: "Quanto espaço temos para crescer acima do pico atual antes de algo quebrar — e o que acontece quando quebra?"
  • Teste de escalabilidade: "Se dobrarmos o investimento em infraestrutura, dobramos de fato a capacidade — ou existe um teto que dinheiro, sozinho, não resolve?"
  • Teste de pico: "Se uma campanha, um lançamento ou uma menção viral multiplicar nosso tráfego em minutos, o sistema absorve isso — ou trava exatamente no momento de maior visibilidade da marca?"
  • Teste de resiliência (soak): "Depois de operar sob carga por um período prolongado, o sistema permanece estável — ou começa a degradar progressivamente até um ponto de ruptura?"

Como o próprio autor resume, a pergunta que a liderança deveria fazer não é "fizemos um teste de desempenho?" — vaga o suficiente para aceitar qualquer resposta como satisfatória —, mas qual desses riscos o teste específico foi desenhado para responder, e quais permanecem sem resposta. Um programa maduro de teste de desempenho não escolhe um único tipo de teste e o repete indefinidamente: escolhe o tipo certo para o risco certo, no momento certo do calendário do negócio.

Como o sistema deveria reagir sob pressão

Além de identificar o limite, o diagnóstico precisa avaliar como o sistema se comporta ao se aproximar dele. Arquiteturas resilientes usam alguns mecanismos para transformar uma queda total em uma degradação parcial e controlada:

  • Filas e limites de consumo: em vez de aceitar tudo de uma vez, o excesso de requisições é enfileirado e processado em um ritmo que o sistema suporta.
  • Circuit breaker: quando uma dependência externa começa a falhar ou ficar lenta, o sistema para de chamá-la temporariamente e responde com um valor em cache ou uma mensagem de indisponibilidade, em vez de travar esperando um timeout.
  • Isolamento de recursos (bulkhead): pools de conexão e threads separados por função crítica (ex.: checkout) evitam que uma consulta lenta em outra parte do sistema derrube o fluxo mais importante.
  • Retentativas com backoff e jitter: novas tentativas após falha usam intervalos crescentes e aleatorizados, evitando que todos os clientes tentem de novo exatamente ao mesmo tempo e recriem o problema.
  • Degradação graciosa: quando um recurso não essencial fica indisponível, o sistema reduz funcionalidade (por exemplo, desativa recomendações personalizadas) em vez de cair por inteiro.

Quando e com que frequência testar

Como referência prática: testes de carga fazem parte do ciclo normal de releases; testes de estresse valem a pena antes de eventos sazonais importantes (a cada trimestre ou antes de picos conhecidos); testes de pico devem rodar sempre que houver expectativa de um salto de 5 a 10 vezes no tráfego em poucos segundos (Black Friday, campanha de marketing, abertura de matrícula); e testes de resistência ajudam a pegar vazamentos de memória após mudanças relevantes em cache, pool de conexões ou gerenciamento de sessão.

Esse risco, no entanto, não se resolve só com engenharia: ele também é uma decisão de governança. Quando quem responde pelo negócio não tem vocabulário para questionar um "passou no teste" superficial, o risco de desempenho fica invisível até o dia em que ele aparece como queda de receita.

Próximo passo: estime o pico mais provável, modele o cenário com o tipo de teste certo (carga, estresse, pico ou resistência) e execute antes da janela crítica — não no dia em que o erro custa caro.

Referências