Teste de carga de sistema: quantos usuários ele aguenta e onde quebra

Quantas pessoas o seu sistema aguenta ao mesmo tempo?

A pergunta aparece na reunião antes da campanha, do lançamento ou da assinatura com o cliente grande, e, sem teste de carga, a resposta é um palpite. "Aguenta tranquilo." "Está na nuvem, escala sozinho." "Testamos e estava rápido." Nenhuma dessas respostas é um número, e, para ter esse número antes do dia de pico, é preciso medir.

Teste de carga não é o teste que a sua equipe já faz antes de cada entrega. Aquele confere se o sistema funciona: alguém se cadastra, compra, emite a nota, e tudo dá certo. O teste de carga confere se ele continua funcionando quando milhares de pessoas fazem isso no mesmo minuto, quanto tempo cada uma espera pela resposta e o que quebra primeiro quando o volume passa do limite. Um sistema pode passar em todos os testes do primeiro tipo e cair quando o volume sobe. Já vimos acontecer: um portal com tempo de resposta bom nos testes da equipe caiu, sobrecarregado, numa tarde de testes de aceite do cliente.

Na X-Apps, usamos o k6 para teste de carga. É uma ferramenta de código aberto mantida pela Grafana Labs.

O dia de pico tem data marcada

O livro de SRE (engenharia de confiabilidade) do Google aponta a sobrecarga como a causa mais comum das falhas em cascata: um servidor cai, a carga dele vai para os que sobraram, esses ficam mais perto do limite e caem também, num efeito dominó que derruba o serviço inteiro.

E muitos picos têm data marcada:

• o dia de maior volume do Pix em 2025 foi 5 de dezembro, com 313,34 milhões de operações, segundo o relatório anual do Banco Central, que atribui o movimento acima da média de dezembro ao 13º salário e às festas. Pelo calendário, 5 de dezembro foi também o quinto dia útil do mês, o prazo legal do salário, e o segundo maior dia do ano, 28 de novembro, foi a sexta-feira da Black Friday;
• na Black Friday de 2025, o e-commerce brasileiro faturou R$ 4,76 bilhões e recebeu 8,69 milhões de pedidos num único dia, segundo a Neotrust;
• no Imposto de Renda de 2026, cerca de 13,7 milhões de declarações, quase um terço do total, chegaram nos últimos seis dias do prazo (conta nossa sobre os números da Receita divulgados pela Agência Brasil);
• campanha na TV, post de influenciador e lançamento de produto têm hora marcada pela própria empresa.

Quando o volume não é previsto, ele pode virar notícia. O Banco Central abriu a consulta ao Sistema Valores a Receber em 24 de janeiro de 2022. Na mesma noite a ferramenta ficou instável e, na tarde seguinte, saiu do ar: segundo a Agência Brasil, a demanda inesperada derrubou o site do próprio BC. A consulta só reabriu na noite de 13 de fevereiro, num site exclusivo, separado do resto justamente para que o volume não pusesse o site principal em risco de novo.

Data conhecida dá prazo ao teste: dá para medir semanas antes, corrigir o gargalo e chegar ao dia com o número na mão, em vez de descobri-lo junto com o cliente.

Onde o limite aparece na sua empresa

• Campanha e lançamentoA mídia já está paga. Se o site trava no minuto do anúncio, a campanha paga a queda.
• Data sazonal e prazoBlack Friday, matrícula, declaração: o volume dispara em poucos dias do ano.
• Dia de pagamentoEm 2025, o dia de maior volume do Pix coincidiu com o prazo legal do salário.
• Integração com ERP e parceirosMesmo que o seu sistema aguente, o do outro lado pode ter cota por segundo.
• Cliente novo que dobra a base"O sistema aguenta?" deixa de ser palpite antes de assinar.
• Migração de infraestruturaO mesmo roteiro antes e depois: o ambiente antigo só sai quando o novo bater os mesmos números.
• Sistema que piora com as horasMemória, conexão e disco que se esgotam aos poucos só aparecem depois de muito uso.
• Setor reguladoNo Open Finance, o próprio Banco Central fixa capacidade mínima e tempo de resposta.
• IA em produçãoO provedor do modelo pode limitar pedidos por minuto, e um piloto pequeno talvez nunca chegue a esse limite.

Black Friday e venda de ingressos são os casos de manchete. Integração, crescimento e desgaste ao longo do dia rendem menos manchete e podem aparecer em qualquer empresa que opera sistema próprio.

Integração engana porque o gargalo pode estar fora do seu sistema. O Bling, por exemplo, documenta um limite de 3 requisições por segundo por conta, somando todos os módulos (requisição é cada chamada que um sistema faz ao outro); passou disso, as próximas não são processadas. Num pico de pedidos, se a integração não foi desenhada para esse limite, a loja aceita a compra e é a sincronização com o ERP que fica para trás: estoque desatualizado, nota atrasada, e nenhum erro visível para quem compra. Quando a chamada ao ERP fica no meio do caminho do usuário, o efeito aparece na tela: num dos nossos projetos, o login de um portal parou porque a API do ERP do cliente (a porta pela qual um sistema conversa com outro), chamada no momento do login, demorava demais para responder.

Com IA, o limite também mora no fornecedor. A Anthropic, por exemplo, mede os limites da API em requisições e em tokens por minuto (tokens são os pedaços de texto que o modelo lê e escreve), e avisa na documentação que rajadas curtas já podem estourar o limite. Um assistente que respondeu bem a um piloto pequeno pode começar a devolver erro quando a empresa inteira passa a usar ao mesmo tempo.

Nos dois casos, o limite está na documentação do fornecedor. O teste de carga, feito contra um simulador que respeita esse limite, mostra o que o seu sistema faz quando bate nele, antes do pico, quando ainda dá tempo de desenhar fila, envio em lote e nova tentativa com espera.

Teste de carga, de estresse e de pico: qual a diferença

Todos simulam usuários seguindo um roteiro, a sequência de passos de uma pessoa real (buscar, pôr no carrinho, pagar), e medem o sistema. O que muda é o formato da carga e a pergunta que cada um responde. A documentação do k6 descreve seis tipos:

Fonte: documentação do Grafana k6, guia de tipos de teste, lida em 02/10/2026. A linha tracejada marca a carga de um dia normal.

A diferença entre teste de carga e teste de estresse se resolve pela pergunta. O teste de carga média responde pelo dia normal. O de estresse, pelo dia mais cheio que você espera. O de ruptura, por onde fica o limite e pelo que quebra primeiro.

A ordem importa. A documentação do k6 manda começar pela fumaça e só então subir a carga e a duração, e faz um alerta que vale para quem testa pela primeira vez: o sistema pode ser menos sólido do que parece, e milhares de usuários da ferramenta já derrubaram rapidamente a própria aplicação, ou o ambiente de homologação (a cópia do sistema usada para testes), num teste de carga.

O teste de resistência procura o que só aparece com o tempo: tempo de resposta que piora aos poucos, memória que vaza, armazenamento que acaba. Nos sistemas que operamos, já vimos API cair por disco cheio, um esgotamento que se acumula com o uso e que um teste curto termina antes de mostrar. Para quem opera sistema que não pode parar, é o teste que procura o vazamento antes que o reinício programado vire rotina.

Nenhum tipo, sozinho, cobre tudo, e a própria documentação diz isso. A combinação depende de onde está o risco do seu sistema, e é ela que define o escopo do teste: não é preciso pedir os seis tipos, e sim os que respondem à pergunta do seu próximo pico. Quem vai anunciar na TV precisa do teste de pico; quem opera sistema que roda o dia inteiro, do de resistência.

O que o teste entrega: capacidade, tempo de resposta e o ponto de quebra

O resultado que importa para quem decide cabe em quatro respostas:

• capacidade: quantos acessos simultâneos, ou quantas operações por segundo, o sistema atende dentro do combinado;
• tempo de resposta nesse volume, medido em percentil. "95% das respostas abaixo de um segundo" quer dizer que, de cada 100 respostas, 95 chegaram em menos de um segundo. Como cada pessoa recebe várias respostas numa mesma visita, a parcela de pessoas que pegou alguma resposta lenta tende a ser maior que 5%. A média esconde quem esperou muito; o percentil mostra;
• taxa de erro: quantas requisições falharam ou estouraram o tempo;
• onde quebra e como: qual recurso se esgotou primeiro (banco de dados, memória, conexões, serviço de terceiro) e o que corrigir, em ordem de impacto. A ferramenta de carga mede o que o usuário sente, como tempo e erro; o recurso que se esgotou aparece no monitoramento do servidor, ligado durante o teste.

Não é uma régua inventada para teste. O Banco Central usa a mesma régua de capacidade e percentil no Open Finance: a infraestrutura das instituições tem de atender no mínimo 300 requisições simultâneas por segundo, e o percentil 95 diário do tempo de resposta tem de ficar em até 1.500 milissegundos nos endpoints (os pontos de acesso da API) que o manual classifica como de alta e média-alta frequência.

O ponto de quebra muitas vezes não chega aos poucos. O livro de SRE do Google observa que muitos componentes não degradam de forma gradual a partir de certo ponto: falham de uma vez. Na prática, a curva tem um joelho.

O quarto marco é o que mais interessa a quem decide, porque o teste não mostra só quando o sistema falha, mostra como. O mesmo livro de SRE recomenda levar cada componente ao limite em teste e observar: o componente vulnerável começa a cair ou a devolver uma taxa muito alta de erros; o bem projetado rejeita alguns pedidos e sobrevive. É a diferença entre uma fila de espera com mensagem clara e uma tela branca para todo mundo, e ela se decide no projeto, antes do pico.

O tempo de resposta pesa mesmo quando nada cai. Num experimento controlado publicado em 2013, a Microsoft deixou parte dos usuários do Bing 100 e 250 milissegundos mais lentos durante duas semanas, e concluiu que cada 100 milissegundos de melhora valiam 0,6% de receita. Lentidão pode custar dinheiro antes de virar queda.

A nuvem escala sozinha? Até a fatura

Escalonamento automático é um recurso real e útil. Ele não substitui o teste, por três motivos.

Primeiro, existem tetos que ninguém configurou. A AWS, por exemplo, limita por padrão a 1.000 execuções simultâneas no Lambda, o serviço dela que roda trechos de código sob demanda. O teto vale para cada região e soma todas as funções da conta. Dá para pedir aumento, mas só pede quem sabe que vai precisar.

Segundo, nem tudo se multiplica. Servidor de aplicação ganha cópias; o banco de dados principal, a cota de um parceiro e o serviço de terceiro costumam ter limite fixo, e é para eles que o gargalo se muda quando o resto escala.

Terceiro, o limite que sobra é o da conta. A documentação do k6 desaconselha procurar o ponto de ruptura com a elasticidade (o escalonamento automático) ligada, porque o ambiente pode crescer junto com o teste e o único limite encontrado acaba sendo o da fatura da nuvem. Durante esse teste, a recomendação é desligar a elasticidade de todos os componentes envolvidos.

O mesmo número serve no sentido contrário, e aí ele pode economizar. Quem sabe quantos usuários cada servidor atende tem base para pagar só a capacidade de que precisa. Já revisamos infraestrutura com processador e memória sobrando tanto em homologação quanto em produção. Máquina superdimensionada também é defeito; só que ele aparece na fatura, e não na tela.

Onde rodar o teste sem derrubar o que já funciona

Teste de carga gera tráfego de verdade, e mal dosado derruba o que estava medindo. Por isso a escolha do ambiente é uma troca:

• homologação com infraestrutura mínima não mede desempenho, porque não reproduz a produção. A documentação do k6 a recomenda para o teste de fumaça, inclusive rodando a cada entrega;
• um ambiente com a mesma configuração da produção é o lugar natural para carga média, estresse e ruptura;
• produção dá o resultado mais fiel e é a opção mais arriscada. Quando ela é a única viável, a documentação recomenda carga menor no horário de pico, testes fora do pico e tipos de teste menos agressivos.

Uma regra não muda com o ambiente: não se testa servidor que não é seu. A documentação do k6 manda desligar no teste as chamadas a terceiros, como autenticação, compartilhamento em redes sociais e analytics, salvo permissão. Pela mesma lógica, gateway de pagamento e ERP do parceiro saem do teste ou vão para um simulador que responda no tempo e no limite do parceiro real, porque simulador que responde na hora deixa o teste otimista. Disparar milhares de chamadas contra o ERP de produção de um parceiro é, ao mesmo tempo, um teste ruim e um problema de relacionamento.

Um plano de teste de carga responde a isso antes da primeira execução: em que ambiente roda, em que horário, com que carga máxima, contra quais serviços e quem acompanha.

Por que usamos o k6

O k6 começou a ser desenvolvido em 2016 e é mantido pela Grafana Labs, que anunciou a compra da empresa por trás dele em junho de 2021. A versão 1.0 saiu em maio de 2025 com a promessa de correções críticas por pelo menos dois anos para cada versão principal, e a 2.0 saiu em maio de 2026. Para quem contrata, isso conta: a ferramenta tem empresa responsável e prazo público de correção para cada versão principal. Quatro características explicam por que ele serve ao tipo de sistema que construímos.

O teste é código. O roteiro é escrito em JavaScript, fica no repositório junto do sistema e é versionado como qualquer outro arquivo. O motor que executa o teste é escrito em Go. Para quem contrata, isso significa que o teste pode continuar com a empresa quando o projeto acaba, desde que o roteiro faça parte da entrega: roda de novo na próxima versão, antes do próximo pico, com outra equipe.

Ele roda na esteira de entrega. A esteira é a sequência automática que confere e publica cada versão nova do sistema. Os critérios de aprovação, que o k6 chama de thresholds, fazem o teste terminar reprovado quando o tempo de resposta ou a taxa de erro passa do combinado, e a ferramenta devolve erro para a esteira. No começo, o resultado serve de alerta para investigar; a própria documentação recomenda não confiar só no aprovado ou reprovado enquanto o processo de verificação não estiver maduro.

Ele permite simular a chegada de clientes como na vida real. No modelo que a documentação chama de aberto, os usuários virtuais (robôs que repetem o roteiro como se fossem clientes) chegam num ritmo definido, mesmo que o sistema esteja respondendo devagar. É o que acontece na vida real: quando o site fica lento, os clientes não param de chegar, e a fila cresce. No modelo fechado, cada usuário virtual espera a resposta antes de começar de novo, e a própria lentidão do sistema reduz a carga que ele recebe. Por isso, quando a pergunta é o ritmo de chegada, como num site aberto ao público, o modelo fechado pode medir um tempo de resposta melhor do que o cliente veria no pico e aprovar um sistema que não aguenta. Os dois modelos existem porque servem a objetivos diferentes, e a escolha entre eles faz parte do plano de teste.

Uma máquina gera muita carga. Segundo a documentação, uma única instância do k6 pode simular de 30 a 40 mil usuários virtuais, conforme os recursos da máquina. Para quem contrata, isso significa pouca máquina para gerar a carga do teste. Para escala maior, o mesmo roteiro roda distribuído em várias máquinas, num cluster Kubernetes (um conjunto de servidores administrado como se fosse um só), ou no Grafana Cloud k6, a versão em que a própria Grafana cuida da infraestrutura. Além de sites e APIs, ele testa conexões em tempo real (WebSockets) e gRPC (outro formato de conversa entre sistemas) sem extensão, controla um navegador real quando a experiência na tela importa e envia os resultados para destinos como Grafana Cloud k6, Prometheus e Datadog.

Para quem implementa, um roteiro no modelo aberto, com os critérios no próprio arquivo, tem esta cara (valores de exemplo; o limite de 1.500 ms copia a régua do Open Finance):

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  scenarios: {
    carga_no_catalogo: {
      executor: 'ramping-arrival-rate', // modelo aberto
      startRate: 10,
      timeUnit: '1s',
      preAllocatedVUs: 200,
      stages: [
        { target: 50, duration: '5m' },  // sobe a 50/s
        { target: 50, duration: '20m' }, // sustenta
        { target: 0, duration: '2m' },   // desce
      ],
    },
  },
  thresholds: {
    http_req_failed: ['rate<0.01'],    // erro < 1%
    http_req_duration: ['p(95)<1500'], // p95 < 1,5 s
  },
};

export default function () {
  const res = http.get('https://preprod.example.com/api/produtos');
  check(res, { 'status 200': (r) => r.status === 200 });
}

Gerar a carga deixou de ser o custo principal. Quando a Grafana anunciou a compra, o CEO Raj Dutt lembrou que teste de carga exigia investimento caro em infraestrutura, e por isso só as iniciativas com mais dinheiro colhiam o benefício. Hoje a máquina que gera a carga pode custar pouco: a solução de teste de carga distribuído que a própria AWS publica estima cerca de US$ 30,90 por mês na configuração padrão, num exemplo com dez contêineres (pequenos servidores alugados sob demanda) gerando carga por 30 horas no mês, na região da Virgínia, nos Estados Unidos, com preço sujeito a mudança. O custo de um teste de carga está no trabalho: entender o pico real do negócio, escrever o roteiro com os fluxos que importam, preparar dados e ambiente, rodar, interpretar e corrigir.

Há empresa brasileira que transformou o resultado em argumento de venda. A Cumbuca, instituição de pagamento, publica no próprio site o resumo de um teste de abril de 2026 feito com k6: 52 mil requisições por segundo, com 0,001% de erro (o número em destaque na página), e o teto encontrado na porta de entrada, e não no sistema em si: o balanceador de carga, componente que distribui o tráfego entre os servidores, não dava conta de abrir mais conexões criptografadas novas. É um bom retrato do que o teste entrega: além do número, o lugar onde quebra, que pode estar fora da aplicação. Grafana Labs, Cumbuca e as demais empresas citadas são externas à X-Apps e aparecem aqui pelo que publicam.

Fazer o teste com quem desenvolve o sistema tem uma vantagem prática. O relatório de um teste de carga termina numa lista de gargalos, e alguém precisa corrigir cada um e rodar de novo. Quando a mesma equipe escreve o código e o roteiro, a correção não depende de um segundo fornecedor. O teste de carga faz parte do nosso serviço de QA e automação de testes quando o risco do sistema é de volume.

Quando outra ferramenta faz mais sentido

O k6 não é a única boa opção, e trocar de ferramenta pode não ser a prioridade. Se a sua equipe já mantém planos de teste que funcionam, o que importa é que o teste exista, rode antes do pico e tenha critério.

Fonte: repositórios oficiais e documentação de cada projeto, lidos em 02/10/2026.

No JMeter, a própria documentação reserva a interface gráfica para montar o plano e manda rodar o teste de carga pela linha de comando, sem a interface. Em interesse da comunidade, medido em estrelas no GitHub em outubro de 2026, o k6 tinha mais de 31 mil, o maior número entre as cinco, seguido de perto pelo Locust. Estrela mede interesse no projeto, não quantas empresas usam. As cinco têm o núcleo em código aberto; a coluna de licença é a que o jurídico confere antes de adotar.

Quando o teste de carga não é a primeira coisa a fazer

Nem toda queda é volume. Num portal que operamos, o sistema saiu do ar com poucas pessoas usando. Na análise, o processador estava folgado, sobrava memória, e o log não dizia por que o processo tinha parado. Um teste de carga nesse sistema mediria a coisa errada. O primeiro passo ali era outro: log que registra o motivo da falha, métricas de recurso e alerta. O teste mostra o limite; o monitoramento mostra o que está acontecendo agora, e um não substitui o outro.

Num sistema interno com poucos usuários e sem pico previsível, também não vale começar pelo teste completo. Para ele, um teste de fumaça na esteira e um bom monitoramento são o ponto de partida.

O teste também não cobre o que ninguém previu. O livro de SRE do Google faz ressalva parecida sobre planejamento de capacidade: ele reduz a chance de falha em cascata, mas não basta, porque falhas na distribuição do tráfego entre servidores, cortes de comunicação entre partes da rede ou aumentos inesperados de tráfego podem concentrar carga num ponto além do planejado. O teste de carga reduz a parte do risco que dá para conhecer antes. A outra parte é trabalho de operação.

O que colocar no contrato

Se o desempenho com o volume real não estiver escrito, ele não é critério de aceite, e quando o problema aparecer o projeto pode já ter sido encerrado. A cláusula é curta. Com os números do seu negócio no lugar das letras:

N vem do pico real, não da média: o histórico de acesso, a campanha que vai ao ar, a data do seu calendário. O roteiro é entregue junto com o código, para o teste rodar de novo sem depender de quem o escreveu. E o teste de fumaça entra na esteira, para conferir cada versão nova com carga mínima e acusar cedo uma piora, com o teste completo repetido antes de cada data de pico conhecida.

Perguntas frequentes

Fontes

• Grafana k6, documentação oficial (tipos de teste, thresholds, checks, modelo aberto e fechado, protocolos, saída de resultados, testes grandes, testes automatizados e teste de sites), repositório grafana/k6 e notas das versões 1.0.0, 2.0.0 e 2.3.0. Lidos em 02/10/2026.
• Grafana Labs, comunicado de 17/06/2021 sobre a compra do k6.
• Google, Site Reliability Engineering, capítulos "Introduction", "Handling Overload", "Addressing Cascading Failures" e "Testing for Reliability", 2016.
• Kohavi et al., "Online Controlled Experiments at Large Scale", KDD 2013, Microsoft.
• Banco Central do Brasil, Relatório Anual do SPI 2025; Instrução Normativa BCB nº 615/2025 (Manual de APIs do Open Finance).
• Planalto, CLT, art. 459.
• Neotrust, painel da Black Friday, lido em 02/10/2026.
• Agência Brasil, matérias de 23/05/2026 e 01/06/2026 sobre o IRPF 2026; de 27/01/2022, 07/02/2022 e 14/03/2022 sobre o Sistema Valores a Receber.
• Bling, página de limites da API para desenvolvedores; AWS, documentação de concorrência do Lambda e página de custo da solução Distributed Load Testing on AWS; Anthropic, documentação de limites da API. Lidos em 02/10/2026.
• Cumbuca, página de escala com o resumo do teste de carga de abril de 2026, lida em 02/10/2026.
• Apache JMeter, Gatling, Locust e Artillery, repositórios e documentação oficiais, lidos em 02/10/2026.
• As experiências relatadas são de sistemas desenvolvidos e operados pela X-Apps, sem identificação de clientes.