Todo sistema tem um limite. A questão não é "se" vai quebrar, mas "onde" e "como". Conhecer o ponto de ruptura permite preparar o sistema para falhar graciosamente, não catastroficamente. Este artigo ensina a encontrar, documentar e usar essa informação.
Sistemas não falham aleatoriamente. Falham em pontos específicos, de formas previsíveis.
O Que É Ponto de Ruptura
Definição
Ponto de ruptura:
A carga ou condição onde o sistema deixa de
atender critérios mínimos de funcionamento
Pode ser definido por:
- Error rate > X%
- Latência > X segundos
- Throughput cai abaixo de X
- Componente crítico falha
- Dados corrompidos
Tipos de ruptura
Soft breaking point:
- Degradação gradual
- Alguns requests falham
- Sistema parcialmente funcional
- Recuperação possível sem intervenção
Hard breaking point:
- Falha catastrófica
- Sistema não responde
- Requer intervenção manual
- Possível perda de dados
Encontrando o Ponto de Ruptura
Teste progressivo
Método:
1. Começar em carga normal
2. Incrementar gradualmente
3. Observar métricas continuamente
4. Identificar primeiro sinal de degradação
5. Continuar até falha
6. Documentar cada threshold
Exemplo:
Step 1: 1000 req/s → OK
Step 2: 1500 req/s → OK
Step 3: 2000 req/s → Degradação (p95 sobe)
Step 4: 2500 req/s → Error rate 5%
Step 5: 3000 req/s → Error rate 30%
Step 6: 3500 req/s → Timeout generalizado
Identificando componentes
Para cada step, identificar:
- Qual componente saturou?
- Qual métrica indicou primeiro?
- Como afetou outros componentes?
Exemplo:
Em 2500 req/s:
- DB connection pool: 100%
- Requests enfileiram
- Timeout em service A
- Service B recebe timeout de A
- Cascata de falhas
Modos de Falha
1. Graceful Degradation
Comportamento:
- Performance reduz gradualmente
- Funcionalidades não-críticas param
- Core continua funcionando
- Recupera automaticamente quando carga baixa
Exemplo:
"Sob 3x carga, busca fica lenta (5s),
mas checkout continua funcionando (1s)"
Implementação:
- Priorização de requests
- Shedding de carga não-crítica
- Circuit breakers
2. Graceful Failure
Comportamento:
- Sistema reconhece overload
- Recusa novos requests (503)
- Completa requests em andamento
- Não corrompe dados
Exemplo:
"Acima de 5000 req/s, retorna 503 para
novos requests mas completa os atuais"
Implementação:
- Rate limiting
- Admission control
- Queue limits
3. Cascading Failure
Comportamento:
- Um componente falha
- Dependentes ficam sobrecarregados
- Falha se propaga
- Sistema inteiro cai
Exemplo:
"DB fica lento → API timeout →
Clientes retry → DB pior →
Todos os serviços falham"
Prevenção:
- Circuit breakers
- Timeouts agressivos
- Retry com backoff
- Isolamento de falhas
4. Byzantine Failure
Comportamento:
- Comportamento inconsistente
- Respostas parcialmente corretas
- Difícil de detectar
- Corrupção de dados possível
Exemplo:
"Sob stress, cache retorna dados
desatualizados misturados com atuais"
Prevenção:
- Validação de dados
- Health checks profundos
- Timeouts estritos
Documentando Pontos de Ruptura
Template de documentação
# Breaking Point Analysis - Sistema XYZ
## Resumo Executivo
- Capacidade máxima sustentável: 2000 req/s
- Soft breaking point: 2500 req/s
- Hard breaking point: 3500 req/s
- Primeiro gargalo: DB connection pool
## Detalhamento por Carga
### 2000 req/s (Capacidade Máxima Sustentável)
| Métrica | Valor | Status |
|---------|-------|--------|
| p95 Latency | 250ms | ✓ OK |
| Error Rate | 0.3% | ✓ OK |
| CPU | 75% | ✓ OK |
| DB Connections | 80% | ⚠ Warning |
**Observação**: Operação estável, headroom limitado
### 2500 req/s (Soft Breaking Point)
| Métrica | Valor | Status |
|---------|-------|--------|
| p95 Latency | 800ms | ⚠ Degraded |
| Error Rate | 3% | ⚠ Degraded |
| CPU | 85% | ✓ OK |
| DB Connections | 100% | ❌ Saturated |
**Observação**: DB connection pool saturado.
Requests enfileiram. Sistema ainda funcional.
### 3500 req/s (Hard Breaking Point)
| Métrica | Valor | Status |
|---------|-------|--------|
| p95 Latency | >30s | ❌ Failed |
| Error Rate | 45% | ❌ Failed |
| CPU | 95% | ⚠ High |
| DB Connections | 100% | ❌ Saturated |
**Observação**: Cascata de timeouts.
Sistema não-funcional para maioria dos usuários.
## Sequência de Falha
1. DB connection pool atinge 100%
2. Requests aguardam conexão (latência sobe)
3. Timeouts começam após 5s
4. Clientes fazem retry (carga aumenta)
5. Mais timeouts, mais retries
6. Efeito cascata até falha generalizada
## Componente Crítico
- **Componente**: PostgreSQL connection pool
- **Limite atual**: 100 conexões
- **Sugestão**: Aumentar para 200 ou implementar PgBouncer
## Modo de Falha Observado
- **Tipo**: Cascading failure
- **Recuperação**: Manual (restart necessário acima de 4000 req/s)
- **Tempo de recuperação**: ~5 minutos após redução de carga
## Recomendações
1. Implementar circuit breaker para DB
2. Aumentar connection pool ou usar pooler
3. Adicionar rate limiting em 2200 req/s
4. Alertar em DB connections > 70%
Usando a Informação
Para capacity planning
Dado:
- Soft breaking point: 2500 req/s
- Crescimento esperado: 50% ao ano
- Carga atual: 1000 req/s
Cálculo:
- Headroom atual: 2.5x
- Em 1 ano: 1500 req/s (1.67x headroom)
- Em 2 anos: 2250 req/s (1.1x headroom) ⚠
Ação:
Planejar escala ou otimização antes de 18 meses
Para alertas
Alertas baseados em breaking point:
Warning (70% do soft breaking):
- DB connections > 70%
- p95 > 200ms
- CPU > 60%
Critical (90% do soft breaking):
- DB connections > 90%
- p95 > 500ms
- Error rate > 1%
Emergency (hard breaking iminente):
- DB connections = 100%
- p95 > 2s
- Error rate > 10%
Para runbooks
## Runbook: Sistema sob stress
### Indicadores
- Error rate acima de 2%
- Latência p95 acima de 1s
- DB connections acima de 90%
### Ações Imediatas
1. Verificar tráfego (spike real ou ataque?)
2. Se spike legítimo:
- Ativar rate limiting
- Escalar horizontalmente se possível
3. Se ataque:
- Ativar WAF rules
- Bloquear IPs suspeitos
### Mitigação
- Desativar features não-críticas
- Reduzir batch sizes
- Aumentar timeout (com cuidado)
### Escalação
- Se não resolver em 10 min → On-call SRE
- Se degradação > 50% → Incident commander
Prevenindo Falhas Catastróficas
Mecanismos de proteção
Rate Limiting:
- Limitar requests por cliente
- Priorizar por tipo de request
- Configurar baseado em 80% da capacidade
Circuit Breakers:
- Por dependência externa
- Fail fast quando dependência degradada
- Auto-reset após período
Load Shedding:
- Rejeitar requests quando saturado
- Priorizar requests críticos
- Retornar 503 com Retry-After
Bulkheads:
- Isolar componentes críticos
- Pool separados por função
- Evitar que falha se propague
Conclusão
Conhecer o ponto de ruptura permite:
- Planejar capacidade - quando escalar antes de quebrar
- Configurar alertas - avisar antes de degradar
- Preparar runbooks - saber o que fazer
- Implementar proteção - falhar graciosamente
- Comunicar riscos - informar stakeholders
Todo sistema tem limites. A diferença está em conhecê-los e estar preparado.
Não é questão de "se" vai quebrar, mas "quando" e "como". Esteja preparado para ambos.
Este artigo faz parte da série sobre a metodologia OCTOPUS de Performance Engineering.