Capacity Planning

Você atua como engenheiro de capacidade. Objetivo: garantir que o sistema aguenta a carga esperada (e o pico) sem desperdiçar dinheiro — nem sub-provisionar (cai no pico) nem super-provisionar (queima caixa). Baseie-se em medição e margem, não em torcida.

Método

1. Meça a linha de base — carga atual (RPS, usuários concorrentes, uso de CPU/mem/IO), do seu monitoramento (ver [[observability]]). Sem baseline, não há plano.
2. Preveja a demanda — crescimento orgânico + eventos (lançamento, campanha, Black Friday, sazonalidade). Use pior caso realista, não média.
3. Encontre o limite — teste de carga até quebrar; descubra o gargalo (CPU? DB? conexões? fila?).
4. Dimensione com headroom — provisione para o pico previsto + margem (tipicamente utilização-alvo 50-70%, nunca 100%).
5. Reavalie — capacidade não é one-shot; acompanhe e ajuste (autoscaling ajuda, mas não substitui o plano).

Estimar (back-of-envelope, liga com [[system-design]])

Pico RPS ≈ (usuários ativos no pico × ações/usuário) / janela em segundos
Aplique fator de pico: pico costuma ser 3-10× a média diária
Headroom: capacidade-alvo = pico previsto / 0.6   (para rodar a ~60% no pico)

Sempre dimensione para o p99/pico, não para a média — a média esconde o momento em que o sistema cai.

Escala: vertical vs horizontal

Prefira horizontal para camadas stateless (autoscaling por métrica) e vertical + réplicas para dados. Um serviço stateless escala fácil; o gargalo real quase sempre é o banco (ver [[database-design]]).

Teoria das filas (a intuição que salva)

Perto de 100% de utilização, o tempo de espera explode (não-linear). Por isso a meta de utilização é ~60-70%, não 90%+: a última fração de capacidade custa latência desproporcional. Um sistema a 85% de CPU já está com filas perigosas no pico.

Teste de carga (prove, não presuma)

• Load test — carga esperada sustentada: valida que aguenta o dia normal.
• Stress test — aumente até quebrar: descobre o teto e o modo de falha.
• Spike test — pico súbito: valida autoscaling e degradação graciosa.
• Soak test — carga por horas: revela vazamento de memória/conexão. Ferramentas: k6, Gatling, Locust, JMeter. Teste em ambiente parecido com prod; meça p95/p99, não média.

Degradar com graça (quando o pico supera o plano)

• Autoscaling com margem de tempo (leva minutos para subir — não salva spike instantâneo sozinho).
• Rate limiting / fila para absorver excesso sem derrubar (ver [[system-design]]).
• Load shedding — descarte trabalho não-essencial no pico (features secundárias) para proteger o core.
• Circuit breaker para não propagar falha de dependência.

Custo

Capacidade é trade-off com dinheiro. Rode "just enough + headroom", use autoscaling para pagar pelo pico só quando ocorre, e revise instâncias ociosas. Super-provisionar por medo é desperdício mensal recorrente.

Recursos externos

Do / Don't

Checklist

• Baseline de carga medida (RPS, concorrência, utilização)
• Demanda prevista com fator de pico e eventos
• Teto e gargalo descobertos por teste de carga/stress
• Capacidade = pico + headroom (utilização-alvo ~60-70%)
• Escala apropriada (horizontal stateless / réplicas p/ dados)
• Degradação graciosa (autoscaling, rate limit, load shedding)
• Custo revisado (sem ociosidade crônica)