Não existe um número universal. A capacidade de um sistema depende da jornada de negócio testada, do perfil real dos usuários, do volume e da distribuição dos dados, das integrações externas envolvidas, da configuração do ambiente e — principalmente — dos critérios de tempo de resposta e taxa de erro que definem o que "aguentar" significa. Um mesmo sistema pode, com razão, responder "2.000" para uma jornada de consulta simples e "200" para um checkout com integração de pagamento.

O que realmente determina a capacidade de um sistema

Throughput — a quantidade de transações que um sistema processa por segundo — responde a uma pergunta concreta de negócio: quantos clientes simultâneos a operação consegue efetivamente atender antes que a experiência comece a se deteriorar para todo mundo? Esse limite é sempre específico de uma jornada, sob uma carga e em comparação com uma referência definida — nunca uma propriedade genérica do sistema como um todo. Latência medida em um ambiente de testes tranquilo, sem tráfego concorrente real, diz muito pouco sobre o que o cliente vai experimentar num dia de pico.

Isso também explica por que um teste executado em ambiente de homologação — com volume de dados reduzido, sem a concorrência real de milhares de usuários simultâneos e com integrações de terceiros simplificadas — não pode ser extrapolado com confiança para produção. A pergunta que separa um resultado útil de um resultado decorativo é: esse ambiente de teste se parece o bastante com produção, em volume de dados, carga concorrente e integrações reais, para que o resultado signifique algo?

Como estabelecer uma baseline de capacidade confiável

A forma confiável de responder "quantos usuários simultâneos aguento" é estabelecer uma baseline de capacidade: uma medição controlada, sob carga gerada por usuários virtuais — o conceito usado por praticamente toda ferramenta de teste de carga moderna, como k6 e Gatling, para simular sessões de usuários reais executando uma jornada em paralelo —, que indique quantos desses usuários virtuais o sistema suporta enquanto os indicadores definidos se mantêm dentro do critério de aceite.

Um critério de aceite bem definido responde a três perguntas antes de o teste começar, não depois: qual volume de uso o sistema precisa suportar (usuários simultâneos, transações por segundo ou pedidos por minuto); qual tempo de resposta máximo é aceitável sob esse volume, do ponto de vista de quem usa o sistema; e qual taxa de erro o negócio está disposto a tolerar sem considerar o teste reprovado. A FATTO enquadra esse escopo por jornadas, endpoints e volume de usuários virtuais, com pacotes dimensionados à complexidade do ecossistema testado:

PacoteUsuários virtuais
EssentialAté 1.000
StandardAté 5.000
AdvancedEcossistemas maiores
CustomAcima de 20.000

Por que sem baseline o número não tem valor

Um sistema que "aguenta 2.000 usuários" sem critério de tempo de resposta, jornada e dados definidos não diz nada — é tecnicamente compatível tanto com um sistema operando com folga considerável quanto com um sistema a poucos pontos percentuais de um colapso completo. Dois resultados podem ser igualmente "aprovados" segundo o mesmo critério de volume e, ainda assim, representar riscos completamente diferentes: um sistema aprovado operando a 60% de sua capacidade máxima carrega uma margem de segurança confortável; o mesmo sistema aprovado a 95% está, na prática, a um pico inesperado de distância de um incidente. A pergunta certa nunca é apenas "passou?", mas "passou com que margem?".

Vale notar que concorrência (quantos usuários estão "dentro" do sistema em um dado instante) e throughput (quantas transações o sistema processa por segundo) são relacionados, mas não são a mesma coisa — a relação entre eles depende diretamente do tempo de resposta de cada transação. Um sistema mais lento naturally acumula mais usuários simultâneos "presos" dentro dele para o mesmo volume de chegada, o que é, por si só, um argumento a favor de medir concorrência real sob carga, e não estimá-la a partir de suposições soltas sobre tráfego.

Próximo passo: defina a jornada, o volume esperado, o tempo de resposta aceitável e a taxa de erro tolerável antes de declarar qualquer número de capacidade — e meça a margem de segurança, não apenas o veredito de aprovação.

Passo a passo: como medir isso na prática com o Apache JMeter

Entre as ferramentas de teste de carga, o Apache JMeter é a mais usada no mercado — código aberto, gratuita, com mais de duas décadas de maturidade e a maior base de usuários e comunidade entre as opções disponíveis hoje. É uma escolha sólida para qualquer time que ainda não tem uma baseline de capacidade estabelecida. O roteiro abaixo mostra como chegar a um número confiável de usuários simultâneos, na prática.

  1. Defina a jornada e instale o JMeter. Baixe o Apache JMeter (gratuito, multiplataforma) e escolha uma única jornada de negócio para começar — login, busca de produto ou checkout, por exemplo. Testar "o sistema todo" de uma vez raramente produz um número acionável; testar uma jornada específica produz.
  2. Crie um Thread Group representando os usuários virtuais. No Test Plan, adicione um Thread Group e configure três valores: número de usuários virtuais (threads), tempo de ramp-up (quanto tempo o JMeter leva para "ligar" todos os usuários) e número de repetições ou duração do teste. Comece com um volume próximo ao tráfego típico atual — esse é o seu ponto de partida, não o teto.
  3. Configure as requisições HTTP da jornada. Adicione um HTTP Request Sampler para cada passo da jornada (por exemplo: abrir página, autenticar, adicionar ao carrinho, finalizar pedido), na ordem em que o usuário real navegaria. Para jornadas mais complexas, o HTTP(S) Test Script Recorder permite gravar a navegação uma vez e gerar as requisições automaticamente.
  4. Defina o critério de aceite antes de rodar. Adicione uma Duration Assertion (tempo de resposta máximo aceitável) e uma Response Assertion (validação de que a resposta retornou o conteúdo esperado, não apenas um código de status). Esse é o critério de aceite decidido antes do teste — sem ele, qualquer resultado é interpretável da forma mais conveniente depois.
  5. Rode sempre em modo não-GUI (linha de comando), nunca a carga real pela interface gráfica. A interface do JMeter consome recursos que distorcem o próprio resultado do teste. O comando de referência gera o log de resultados e o relatório HTML no mesmo passo:
    jmeter -n -t jornada-checkout.jmx -l resultado.jtl -e -o relatorio/
  6. Aumente o volume de usuários virtuais em rodadas sucessivas. Repita a execução elevando o número de threads a cada rodada (por exemplo, dobrando o volume) até que o tempo de resposta ou a taxa de erro ultrapassem o critério definido no passo 4. O ponto exato em que isso acontece é a capacidade real da jornada testada.
  7. Leia o relatório HTML gerado (pasta `relatorio/`) e calcule a margem de segurança. O dashboard mostra tempo de resposta por percentil, throughput e taxa de erro ao longo do teste. Compare o volume de tráfego real atual com o volume em que o sistema começou a degradar — essa distância é a margem de segurança, o dado que efetivamente importa para qualquer decisão de negócio.
  8. Documente a baseline e marque a data do próximo reteste. Registre volume suportado, margem de segurança, jornada testada e data do teste. Essa baseline vale até a próxima mudança relevante — novo deploy, crescimento de base de usuários ou migração de infraestrutura — não indefinidamente.

Referências e leituras complementares