Artigo · 18 min · 27 de julho de 2026
Um guia prático sobre ambientes sandbox, testes de carga, stress, spike e soak — e como descobrir os limites reais da aplicação antes que os usuários descubram.
Diego S. Wilhelmsen
Founder & Technology Lead
Um aplicativo pode funcionar perfeitamente durante desenvolvimento e ainda falhar completamente quando submetido ao comportamento real dos usuários.
O problema é que muitos times validam apenas o "happy path":
Mas sistemas reais enfrentam:
A pergunta correta não é:
"Meu sistema funciona?"
Mas:
"Como meu sistema se comporta quando todos os componentes começam a ser pressionados ao mesmo tempo?"
É nesse cenário que entram os ambientes sandbox e os testes de estresse.
Um sandbox é uma réplica controlada do ambiente real onde podemos provocar situações extremas sem impactar usuários.
Ele deve representar:
Um erro comum é criar um ambiente completamente diferente e depois concluir:
"O teste passou, então estamos preparados."
Mas se o sandbox possui:
o resultado não representa a realidade.
Performance não é apenas medir tempo de resposta.
Existem diferentes dimensões.
Quanto tempo uma operação demora.
Exemplo:
GET /clientes
Tempo médio: 120ms
P95: 350ms
P99: 900ms
O usuário normalmente sente os extremos, não a média.
Uma API pode ter média excelente, mas possuir 1% das requisições demorando vários segundos.
Quantidade de operações suportadas.
Exemplo:
500 requisições por segundo
1000 requisições por segundo
5000 requisições por segundo
O objetivo é descobrir:
Qual é o limite sustentável?
Quantidade de usuários executando ações simultaneamente.
Exemplo:
10 usuários 100 usuários 1.000 usuários 10.000 usuários
Muitos sistemas funcionam bem com usuários sequenciais, mas quebram quando existe competição por recursos.
Avaliar:
O objetivo é validar o comportamento esperado.
Exemplo:
Uma aplicação suporta:
Criamos uma carga próxima dessa realidade.
Aqui começamos a ultrapassar os limites.
Exemplo:
500 usuários 1000 usuários 5000 usuários 10000 usuários
Até responder:
Simula picos repentinos.
Exemplo:
Um aplicativo de ingressos.
Serve para validar:
Muitos problemas aparecem apenas depois de horas.
Exemplo: rodar por 24 horas, 48 horas ou 7 dias.
Encontrando problemas como:
O maior erro é testar apenas endpoints isolados.
Um sistema real é uma cadeia:
Usuário
↓
Frontend
↓
API Gateway
↓
BFF
↓
Microsserviços
↓
Banco
↓
Mensageria
↓
Serviços externos
O teste precisa reproduzir essa jornada.
Muito utilizado atualmente.
Exemplo:
import http from "k6/http";
import { check } from "k6";
export const options = {
vus: 100,
duration: "5m",
};
export default function () {
const response = http.get("https://api.exemplo.com/clientes");
check(response, {
"status 200": (r) => r.status === 200
});
}Permite:
Muito utilizado em ambientes corporativos.
Bom para:
Muito utilizado em arquiteturas modernas.
Tem boa integração com:
Interessante quando o time trabalha muito com Python.
Permite escrever cenários usando código.
Um teste ruim geralmente usa:
Cliente 1 Produto 1 Pedido 1
Mas produção possui:
10 milhões de clientes 500 mil produtos bilhões de registros
O banco muda completamente de comportamento.
Devemos gerar:
Exemplo:
Testar:
Buscar cliente por CPF
com:
100 registros
é completamente diferente de:
100 milhões de registros
Um teste sem observabilidade é apenas um gerador de tráfego.
Durante a execução devemos acompanhar:
Perguntas importantes:
Um endpoint simples pode derrubar uma aplicação:
SELECT *
FROM pedidos
ORDER BY created_at DESC;Se existir milhões de registros.
Testar:
Um sistema pode funcionar enquanto o cache existe e falhar quando ele expira.
Simular:
Exemplo:
Uma abordagem madura:
Descobrir comportamento normal.
Exemplo:
100 usuários
P95: 300ms
Erro: 0%
Aumentar:
100 500 1000 5000 10000 usuários
Observar o ponto de ruptura.
Perguntar:
"O primeiro componente que falhou foi qual?"
Pode ser:
Aplicar:
Performance é um ciclo.
Medir -> Encontrar gargalo -> Corrigir -> Medir novamente
Teste:
Adicionar máquina maior resolve até certo ponto.
Mas servidor maior não resolve:
Nunca executar stress test sem:
Um teste mal planejado pode derrubar:
Antes de executar qualquer teste de carga ou estresse, é necessário criar um ambiente onde seja possível reproduzir comportamentos extremos sem comprometer usuários reais.
O objetivo do sandbox é funcionar como um laboratório controlado, permitindo alterar configurações, aumentar consumo de recursos, simular falhas e repetir experimentos até encontrar os limites da aplicação.
Um sandbox eficiente não precisa necessariamente ter o mesmo tamanho da produção, mas deve preservar os mesmos comportamentos arquiteturais:
Uma das formas mais simples de criar isolamento.
Exemplos:
A ideia é criar uma máquina dedicada para testes.
Vantagens:
Configuração:
CPU: 4 cores RAM: 16GB SSD: 100GB
Docker instalado
Containers:
Para aplicações modernas, normalmente é a opção mais prática.
Em vez de criar máquinas completas, criamos ambientes isolados por serviço.
Exemplo:
# docker-compose.yml
services:
api:
image: app-api
database:
image: postgres
redis:
image: redis
monitoring:
image: grafanaBenefícios:
Para arquiteturas maiores:
Kubernetes Sandbox Cluster
Namespace: | |-- frontend |-- api |-- workers |-- databases |-- monitoring
Permite testar:
Exemplo:
CPU limit: 500m
Memory: 1GB
Replicas: 3 -> 20
Depois de criar o ambiente, o próximo passo é controlar as variáveis.
Um erro comum é criar um ambiente maior que produção.
Exemplo:
Produção:
API: 4 CPUs 8GB RAM
Sandbox:
API: 8 CPUs 32GB RAM
O teste nunca encontrará gargalos.
O ideal é criar cenários:
4 CPUs 8GB RAM
2 CPUs 4GB RAM
1 CPU 2GB RAM
Isso ajuda a entender:
O ambiente precisa ter dados próximos da realidade.
Não basta criar:
100 usuários 10 pedidos 5 produtos
Quando produção possui:
10 milhões usuários 500 milhões registros
Devemos considerar:
Exemplo:
Banco preparado:
Clientes ├── 5 milhões registros
Pedidos ├── 100 milhões registros
Transações ├── 500 milhões registros
Em testes de estresse, integrações externas podem prejudicar a análise.
Exemplo:
Pagamento:
Aplicação | | API Banco Externo
Se o fornecedor estiver lento, você não sabe se o problema está na aplicação.
Soluções:
Exemplo:
Pagamento real
ou
Mock Payment API | | Latência configurável: 200ms 500ms 5s
Todo teste deve responder:
"o que aconteceu?"
Por isso o sandbox precisa possuir:
Exemplo:
Request
200ms API Gateway
500ms Serviço Pedido
5s Banco
100ms Cache
Sem isso, você sabe que ficou lento, mas não sabe por quê.
Uma estratégia:
Executar com pouca carga:
10 usuários
P95: 300ms
100 usuários
500 usuários
1000 usuários
5000 usuários
Exemplo:
Até 2000 usuários: OK
3000 usuários: latência aumenta
5000 usuários: erros começam
Esse é o limite conhecido.
Um sandbox eficiente transforma testes de performance em experimentos controlados.
Em vez de esperar que a produção revele seus problemas, criamos um ambiente onde podemos provocar:
A principal vantagem não é apenas descobrir "quantos usuários o sistema suporta", mas entender como ele se comporta quando começa a falhar e quais decisões arquiteturais precisam ser tomadas antes disso acontecer.
A engenharia de performance não começa quando o sistema está lento. Ela começa quando ainda existe capacidade de provocar falhas de forma segura.
Um bom time não pergunta apenas:
"Quantos usuários meu sistema suporta?"
Ele responde:
O ambiente sandbox é justamente o laboratório onde conseguimos transformar suposições em evidências. Porque sistemas robustos não são aqueles que nunca falham. São aqueles que conhecem seus limites antes que os usuários descubram.
Site Reliability Engineering
Referência fundamental para entender:
https://sre.google/sre-book/table-of-contents/
The Site Reliability Workbook
Mais prático que o primeiro livro.
Aborda:
https://sre.google/workbook/table-of-contents/
Release It!
Um dos livros mais importantes sobre sistemas em produção.
Explora:
Conceitos muito aplicáveis a:
Designing Data-Intensive Applications
Excelente para entender:
Próximo passo
Solicite um orçamento gratuito. Nossa equipe analisa seu cenário e indica o caminho mais eficiente para colocar essas ideias em prática no seu negócio.
LinkedIn Pulse · 10 min · 23 de jul. de 2026
Como o .NET Aspire simplifica orquestração local, service discovery, observabilidade e containers — aproximando o ambiente de desenvolvimento da produção.
Ler artigo →
LinkedIn Pulse · 35 min · 9 de jul. de 2026
Performance não é só velocidade: previsibilidade, resiliência e disponibilidade contínua — e por que Elixir e a BEAM redefinem o que significa um sistema performático.
Ler artigo →
LinkedIn Pulse · 11 min · 21 de jul. de 2026
Virtual Threads, Structured Concurrency e Pattern Matching: por que o Java 21 é um dos maiores avanços da linguagem desde o Java 8 para backend.
Ler artigo →