DEV Community

Cover image for Seu Sistema Está Pronto pro Pico ou Vai Abandonar o Usuário Quando Mais Precisar?
Ed Wantuil
Ed Wantuil

Posted on

Seu Sistema Está Pronto pro Pico ou Vai Abandonar o Usuário Quando Mais Precisar?

#escalabilidade #testesdecarga #testesdeestresse #qualidadedesoftware

Quando grandes pontes são construídas, engenheiros não economizam em testes. Primeiro, simulam cargas extremas em projetos digitais e maquetes. Depois, com a estrutura pronta, realizam testes reais com caminhões pesados e sensores espalhados por toda a obra.

Tudo isso não é só pra garantir que a ponte fique de pé, é pra ela aguentar o pior congestionamento possível.

Agora pense: aviões, elevadores, pneus… Quase tudo que usamos no dia a dia passa por testes rigorosos.
 Então por que, no desenvolvimento de software, tanta gente ainda confia cegamente que “vai dar tudo certo”?

Spoiler: Não vai. E a realidade cobra, e cobra rápido.

🔥 Quando Tudo Vai Pro Espaço (Mesmo em Grandes Empresas)

Recentemente, na liberação da pré-venda do Nintendo Switch 2, até sites gigantes tombaram, incapazes de lidar com a avalanche de acessos. E isso não é um caso isolado. Lembra da venda de ingressos do último show que você tentou comprar?

O problema costuma nascer de um otimismo quase infantil: a crença de que recursos computacionais são infinitos ou de que “problemas de capacidade” são coisa do passado.

Outros ainda jogam a batata quente exclusivamente pra equipe de infraestrutura, ignorando o fato de que garantir escalabilidade e resiliência é responsabilidade de todo o time, devs, QA, arquitetura, produto e afins.

🧪 Planejar, Testar e Validar: O Tríplice Mandamento da Estabilidade

Se você é da área de tecnologia, precisa encarar a realidade: planejar, testar e validar suas aplicações para os momentos de estresse é tão essencial quanto testar uma ponte antes de inaugurá-la.

Não deixe sua entrega ruir exatamente quando ela mais for necessária.

É aí que entram os testes de carga.

🧱 O Que São Testes de Carga?

Testes de carga simulam o comportamento de vários usuários acessando sua aplicação ao mesmo tempo, como se você pudesse provocar, de forma controlada, o pior congestionamento possível na sua "ponte digital".
Esses testes são essenciais para identificar:

  • Gargalos de performance;
  • Pontos frágeis na arquitetura;
  • Limites de capacidade operacional.

Sem eles, você está lançando seu sistema às cegas, apostando que ele vai aguentar qualquer volume de acessos e apostar não é estratégia.
Investir em testes de carga é investir em confiança, estabilidade e, no fim das contas, na experiência do usuário, aquele que não vai te perdoar se o app falhar justamente quando ele mais precisar.

📏 Antes de Testar: Faça a Estimativa Certa

Mas atenção: antes de testar, é essencial estimar corretamente o volume de acesso que você quer simular.
Esse processo começa com a análise de:

  • Picos históricos de uso da aplicação;
  • Projeções para eventos especiais (grandes lançamentos, campanhas de marketing, repercussões inesperadas).

E vai além: você também precisa considerar cenários de falha de infraestrutura, seja no seu data center ou na nuvem.

☁️ Cloud não é invencível: zonas podem cair, regiões inteiras podem ficar indisponíveis por horas.
 Sua aplicação precisa estar preparada para redistribuir a carga e continuar operando.

🧠 Exemplo Prático: Planejando a Carga

Imagine que seu site, em um dia comum, sustenta 2 mil usuários simultâneos no pico.

Agora, considere um evento especial (tipo Black Friday ou lançamento viral) que pode multiplicar esse número por 5.

Além disso, pense na hipótese de uma falha em uma zona da nuvem, que forçaria sua aplicação a redistribuir a carga em apenas metade da infraestrutura disponível.
Nesse cenário, o teste de carga precisa simular:

10 mil usuários simultâneos,
rodando em 50% da sua estrutura atual.

🛠️ Ferramentas Para Testes de Carga

Hoje, existem várias ferramentas, gratuitas e corporativas, que ajudam a simular acessos simultâneos, medir performance e identificar pontos críticos.

Entre as mais conhecidas estão:

  • Apache JMeter
  • K6
  • Locust
  • Artillery
  • Gatling

Vamos focar aqui no K6, que é leve, simples e bem poderosa.

🧪 Criando um Endpoint para Teste com Node.js

Para testar com K6, primeiro vamos subir um serviço local simples com Node.js que sempre retorna um status 200.
Crie o arquivo server.js com o seguinte conteúdo:

const http = require('http');

const server = http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('OK');
});

const port = 3000;
server.listen(port, () => {
  console.log(`Server running at http://localhost:${port}`);
});
Enter fullscreen mode Exit fullscreen mode

Execute com:

node server.js
Enter fullscreen mode Exit fullscreen mode

Agora temos um endpoint local na porta 3000 (ou a que for exibida no terminal).

⚙️ Instalando o K6

Para utilizar o k6 devemos fazer a instalação da seguinte forma.

Linux (Ubuntu):

sudo apt update
sudo apt install gnupg ca-certificates
sudo mkdir -m0755 -p /etc/apt/keyrings
curl -fsSL https://dl.k6.io/key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/k6-archive-keyring.gpg
echo "deb [signed-by=/etc/apt/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt update
sudo apt install k6
Enter fullscreen mode Exit fullscreen mode

Mac:

brew install k6
Enter fullscreen mode Exit fullscreen mode

Windows (com Chocolatey):

choco install k6
Enter fullscreen mode Exit fullscreen mode

🚀 Primeiro Teste de Carga com 50 Usuários
Crie o arquivo load-test.js:

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

export const options = {
    vus: 50,
    duration: '30s',
};

export default function () {
    const res = http.get('http://localhost:3000');
    check(res, { 'status é 200': (r) => r.status === 200 });
}
Enter fullscreen mode Exit fullscreen mode

Esse script simula 50 usuários virtuais (VUs) acessando o endpoint http://localhost:3000 durante 30 segundos. 
Cada VU faz requisições continuamente, e a função check valida se a resposta tem o código de status 200.
Execute-o com:

k6 run teste.js
Enter fullscreen mode Exit fullscreen mode

📊 Interpretando os Resultados do K6

Ao executar devemos ter o retorno algo como print abaixo:




Nele podemos encontrar:

  • checks_total / succeeded / failed: 
Verifica a quantidade total de verificações (check) feitas, quantas passaram e quantas falharam. 
✅ Neste caso: 1.675.407 verificações com 100% de sucesso.


  • 
http_req_duration:
 Tempo total de duração das requisições HTTP (da saída até a resposta).

    • avg: média geral (850.51μs, excelente).
    • med: mediana (618μs).
    • max: tempo máximo (90.91ms).
    • p(90) e p(95): percentis (ex: 95% das requisições levaram até 1.89ms).

  • http_req_failed: 
Percentual de falhas nas requisições.
 ✅ Aqui: 0.00%, nenhuma falha.


  • iteration_duration:
 Duração de cada iteração completa (requisição + lógica de script).

  • vus / vus_max:
 Quantidade de usuários virtuais ativos (aqui foram fixos em 50).


  • data_received / data_sent: 
Volume de dados trafegados durante o teste (283MB recebidos, 139MB enviados).


  • http_reqs:
 Total de requisições realizadas: 1.675.407
> Taxa: ~55.843 requisições/segundo.
 ✅ O resultado mostra que o endpoint respondeu rapidamente, sem erros, mesmo sob alta taxa de requisições simultâneas.

📈 Rampas de Carga: Porque Nem Todo Pico Vem de Uma Vez

Em muitos cenários, não basta testar se a aplicação suporta uma determinada carga de forma imediata. Para entender de fato o comportamento do sistema sob diferentes níveis de pressão, é fundamental aplicar rampas de carga nos testes.

Esse tipo de abordagem permite observar como a aplicação responde à medida que o número de usuários cresce gradualmente, além de ser essencial para avaliar a eficácia da elasticidade (escalabilidade automática) e identificar possíveis gargalos ao longo da curva de crescimento.

Vamos criar um novo código baseado no exemplo anterior que iremos incluir uma rampa de carga. Nesse novo teste, vamos:

  • Simular 50 usuários virtuais nos primeiros 30 segundos;
  • Aumentar para 100 usuários nos 30 segundos seguintes;
  • Manter os 100 usuários por mais 30 segundos;
  • E por fim, reduzir a carga de forma gradual até zero ao longo de 30 segundos.
Em testes reais, o ideal é que esses tempos sejam maiores e ajustados à realidade do seu sistema, refletindo picos esperados de uso com maior fidelidade.

Exemplo com Rampa de Carga
Crie o ramp-load-test.js com o seguinte conteúdo:

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

export const options = {
    stages: [
        { duration: '30s', target: 50 },
        { duration: '30s', target: 100 },
        { duration: '30s', target: 100 },
        { duration: '30s', target: 0 },
    ],
};

export default function () {
    const res = http.get('http://localhost:3000');
    check(res, { 'status is 200': (r) => r.status === 200 });
}
Enter fullscreen mode Exit fullscreen mode

Execute-o com:

k6 run ramp-load-test.js
Enter fullscreen mode Exit fullscreen mode

Esses testes devem ser executados em duração proporcional ao cenário real, aumentando, sustentando e reduzindo a carga como em eventos reais.

🛡️ Use Ferramentas de Observabilidade

Relatórios do K6 são ótimos, mas para diagnósticos profundos, combine os testes com ferramentas como:

  • New Relic
  • Datadog
  • Dynatrace
  • Elastic Stack
  • Splunk

Elas mostram uso de CPU, memória, latência entre serviços, Apdex, etc. Isso transforma dados em decisões reais sobre arquitetura e negócios.

🚨 E Quando Você Não Sabe o Pico?

Em muitos casos, especialmente durante o desenvolvimento de novas aplicações, não teremos um número exato de usuários para simular nos testes de carga. Nesses cenários, é recomendável conduzir um teste de estresse até identificar o ponto de saturação do sistema, sim a principal diferença do teste de carga e de estresse é que o primeiro é utilizado para responder se a aplicação suporta uma determinada carga, em quanto o segundo responde até qual carga a aplicação consegue lhe dar.

Esse tipo de teste permite fornecer ao time de negócio uma visão clara dos limites atuais da aplicação, possibilitando decisões mais conscientes sobre infraestrutura, roadmap de melhorias e comunicação com usuários.

Sim, a principal diferença entre teste de carga e teste de estresse está no objetivo:

  • O teste de carga busca validar se a aplicação suporta uma carga específica dentro de parâmetros aceitáveis.
  • Já o teste de estresse tem como foco descobrir até qual ponto a aplicação consegue lidar com o aumento de carga, identificando o momento em que começa a falhar ou degradar seu desempenho.
Para realizar um teste de carga no K6, basta subir a va quantidade de VUs, e se for necessário aumentar a quantidade de rampas para entender o comportamento em cada etapa.

💡 Dica Final: Elasticidade Também É Desescalar

Ambientes elásticos devem voltar ao normal após o pico. Se os recursos não forem liberados, você pode acabar com:

  • Overprovisioning;
  • Uso desnecessário de máquinas;
  • E, claro, aquela fatura de nuvem mais assustadora que bug em produção 👻💸

🧩 Conclusão: Testar é Prevenir, Não Remediar

Toda ponte, avião ou elevador passa por testes antes de ser usado por milhões de pessoas. No mundo digital, o raciocínio precisa ser o mesmo.
Não espere o caos para descobrir onde sua aplicação falha.
Testes de carga não são “luxo de grandes empresas”, são prática essencial para qualquer sistema que leve a sério a própria estabilidade, reputação e experiência do usuário.
Ignorar isso é aceitar o risco de colapsar quando mais importa.

Top comments (0)