Capacity planning é o processo de determinar quanto recurso você precisa para atender demanda futura. Errar para menos causa outages. Errar para mais desperdiça dinheiro. A arte está em acertar o suficiente.
Capacity planning não é prever o futuro. É estar preparado para ele.
Por Que Capacity Planning
Sem planejamento
Mês 1: Sistema OK
Mês 2: Sistema OK
Mês 3: Crescimento 20%, lentidão
Mês 4: Emergência! Comprar infra às pressas
Mês 5: Infra nova mal configurada, problemas persistem
Com planejamento
Mês 1: Medição e baseline
Mês 2: Projeção de crescimento
Mês 3: Provisionamento antecipado
Mês 4: Sistema absorve crescimento
Mês 5: Revisão e ajuste
Etapas do Capacity Planning
1. Medir o estado atual
Métricas de baseline:
Throughput atual: 5,000 req/s
Latência p95: 150ms
CPU média: 45%
Memória média: 60%
Conexões DB: 80/100
Recursos atuais:
Servidores: 4x c5.xlarge
DB: db.r5.2xlarge
Cache: cache.r5.large
2. Entender a demanda
# Analisar padrões históricos
daily_pattern = analyze_time_series(last_90_days)
# Identificar tendências
growth_rate = calculate_monthly_growth()
# Ex: 15% mês a mês
# Eventos conhecidos
upcoming_events = [
Event("Black Friday", multiplier=5),
Event("Campanha TV", multiplier=2),
Event("Lançamento feature", multiplier=1.5)
]
3. Projetar crescimento
def project_demand(current: float, months: int, growth_rate: float) -> float:
"""Crescimento composto"""
return current * ((1 + growth_rate) ** months)
# Projeção para 12 meses
current_rps = 5000
monthly_growth = 0.15
month_6 = project_demand(5000, 6, 0.15) # 11,568 req/s
month_12 = project_demand(5000, 12, 0.15) # 26,764 req/s
4. Calcular recursos necessários
def calculate_resources(target_rps: float, baseline: dict) -> dict:
"""
Calcula recursos baseado em ratio atual
"""
current_rps = baseline['throughput']
scale_factor = target_rps / current_rps
return {
'servers': ceil(baseline['servers'] * scale_factor),
'db_size': next_size(baseline['db_size'], scale_factor),
'cache_size': next_size(baseline['cache_size'], scale_factor)
}
# Para 6 meses
resources_6m = calculate_resources(11568, baseline)
# {'servers': 10, 'db_size': 'db.r5.4xlarge', 'cache_size': 'cache.r5.xlarge'}
5. Adicionar margens
def add_margins(resources: dict) -> dict:
"""
Adiciona margem para:
- Picos (20%)
- Eventos especiais (50%)
- Erro de estimativa (20%)
"""
margin = 1.2 * 1.5 * 1.2 # ~2.16x
return {
'servers': ceil(resources['servers'] * 1.5),
'db_size': upsize(resources['db_size']),
'cache_size': upsize(resources['cache_size'])
}
Modelos de Projeção
Linear
Crescimento constante absoluto
Mês 0: 5,000 req/s
Mês 1: 5,500 req/s (+500)
Mês 2: 6,000 req/s (+500)
Quando usar: Mercados maduros, crescimento estável
Exponencial
Crescimento percentual constante
Mês 0: 5,000 req/s
Mês 1: 5,750 req/s (+15%)
Mês 2: 6,612 req/s (+15%)
Quando usar: Startups em crescimento, novos produtos
Por eventos
Baseline + picos previstos
Normal: 5,000 req/s
Black Friday: 25,000 req/s (5x)
Campanha: 10,000 req/s (2x)
Quando usar: Negócios sazonais, marketing intensivo
Estratégias de Provisionamento
1. Just-in-time
Provisiona quando utilização > 70%
Desprovisiona quando < 30%
Prós: Custo otimizado Contras: Risco de não escalar a tempo
2. Headroom fixo
Sempre mantém 50% de margem
Se precisa 10 servidores, mantém 15
Prós: Segurança Contras: Custo maior
3. Escalonado
Q1: Provisiona para H1
Q3: Provisiona para H2
Revisão trimestral
Prós: Previsibilidade Contras: Pode sub ou super provisionar
4. Híbrido (recomendado)
Base: provisionamento escalonado
+ Autoscaling: para variações diárias
+ Reserva: para eventos conhecidos
Capacity Planning por Componente
Servidores de Aplicação
Métricas chave:
- CPU utilization
- Memory usage
- Request throughput
- Active connections
Dimensionamento:
rps_per_server: 500
target_rps: 10000
servers_needed: 20
with_margin: 30
Banco de Dados
Métricas chave:
- Queries per second
- Connections
- Storage growth
- IOPS
Dimensionamento:
# Escala vertical geralmente
current_size: db.r5.2xlarge
projected_load: 2x
target_size: db.r5.4xlarge
# Ou read replicas
write_primary: 1
read_replicas: 3
Cache
Métricas chave:
- Hit rate
- Memory usage
- Evictions
- Connections
Dimensionamento:
current_keys: 1M
key_growth: 10%/month
projected_6m: 1.77M
memory_per_key: 1KB
memory_needed: 1.77GB
with_margin: 4GB
Message Queues
Métricas chave:
- Messages per second
- Queue depth
- Consumer lag
- Storage
Dimensionamento:
current_mps: 10000
retention_hours: 24
message_size: 1KB
storage_needed: 10000 * 3600 * 24 * 1KB = 864GB
with_margin: 1.5TB
Documento de Capacity Plan
# Capacity Plan - Q2 2025
## Sumário Executivo
Projetamos crescimento de 15% mensal. Precisamos expandir
infraestrutura antes do fim de Q1 para evitar degradação.
## Estado Atual
| Recurso | Atual | Utilização | Limite |
|---------|-------|------------|--------|
| App servers | 4 | 45% | 80% |
| Database | r5.2xl | 60% | 80% |
| Cache | r5.lg | 70% | 90% |
## Projeção de Demanda
| Métrica | Atual | +3 meses | +6 meses |
|---------|-------|----------|----------|
| RPS | 5000 | 7600 | 11500 |
| Users | 50K | 76K | 115K |
| Storage | 500GB | 650GB | 850GB |
## Recursos Necessários
| Recurso | +3 meses | +6 meses | Custo Delta |
|---------|----------|----------|-------------|
| App servers | 6 (+2) | 10 (+6) | +$2,400/mo |
| Database | r5.2xl | r5.4xl | +$1,200/mo |
| Cache | r5.xl | r5.xl | +$400/mo |
## Timeline
- Semana 1-2: Provisionar app servers
- Semana 3: Migrar database
- Semana 4: Validar e ajustar
## Riscos
- Black Friday (não modelado): pode precisar 3x
- Novo feature viral: demanda imprevisível
## Recomendações
1. Aprovar expansão imediata
2. Configurar autoscaling para picos
3. Revisão mensal de métricas
Erros Comuns
1. Usar média em vez de pico
❌ CPU média: 40%, temos margem
✅ CPU pico: 85%, precisamos escalar
2. Ignorar sazonalidade
❌ Mês passado = próximo mês
✅ Dezembro tem 3x mais tráfego
3. Projeção única
❌ Vamos crescer 15%
✅ Cenários: otimista (25%), esperado (15%), pessimista (5%)
4. Esquecer dependências
❌ App servers OK, pronto
✅ App servers OK, mas DB vai saturar em 2 meses
Conclusão
Capacity planning efetivo requer:
- Dados sólidos: métricas históricas precisas
- Múltiplos cenários: otimista, esperado, pessimista
- Margens adequadas: eventos e erros de estimativa
- Revisão contínua: planos mudam com a realidade
- Alinhamento: negócio, produto e engenharia
Processo recomendado:
Trimestral: revisão completa do capacity plan
Mensal: verificação de métricas vs projeção
Semanal: monitoramento de tendências
Contínuo: alertas de threshold
O melhor capacity plan é aquele que você não precisa usar em emergência.