Planejamento de capacidade

1) O que é o planejamento de capacidade e o que é necessário

O planejamento de capacidade (capacity planning) é um processo sistemático para avaliar e fornecer os recursos necessários para atingir o SLO de metas a um custo mínimo. Não se trata apenas de CPU/memória, mas também de largura de banda das redes, armazenamento, BD/cajas, filas/pneus de eventos, provedores externos (pagamentos/CUS/antifrode) e recursos humanos (on-call, suporte).

• Executar SLO/SLAs mesmo em picos e degradações.
• Minimizar TCO e capital simples (overprovisioning).
• Reduzir o risco de incidentes de esgotamento de recursos (saturation → p99/erro).
• Garantir previsibilidade de lançamentos e campanhas (marketing, torneios, jogos top).

2) Dados de entrada e fontes da verdade

Observabilidade: RPS/Concarração, p50/p95/p99, error-rate, saturação (CPU, mem, disk IOPS, pps/mbps em rede), comprimento de filas, rate limites.
Eventos de negócios: calendários de campanhas, sazonalidade (noite/fim de semana/mega-eventos), regiões/jurisdição.
Tecnolg/fici: lançamentos roadmap, alterações arquitetônicas (por exemplo, criptografia, nova logagem).
Provedores: quotas e serviços de pagamento throughput/CUS/correio/antifrode.
Incidentes do passado, onde há um lugar estreito (BB, kesh, balanceador L7, pneu, CDN, disco).

3) Conceitos básicos e fórmulas

Headroom - reserva por capacidade: 'headroom = (max _ sustentável _ RPS - real _ RPS )/max _ sustentável _ RPS'.
Destino no pico de 20 a 40% (para fluxos críticos).
Saturation é a relação entre o recurso ocupado e o disponível (CPU%, memória/GC, conexões, arquivos descriptors, IOPS, profundidade da fila).
Throghput sustentável é a velocidade em que p99 e error-rate executam SLO de longa duração (não uma vez).
O Capacity Unit (CU) é uma unidade de energia racionada para o serviço (por exemplo, X RPS por pod vCPU=1, RAM = 2 GiB).
O limite do sistema é max sem degradação: 'N _ pods x CU'. É importante considerar as dependências shared (BD/kesh/pneu).

4) Modelo de demanda: previsão

Filas estatísticas: sazonalidade semanal/diária, feriados, finais desportivos, picos regionais.
Côrtes: países, provedores de pagamentos, dispositivos, segmentos VIP.
Delta de eventos: influência de campanhas/canhão/lançamento/SEO.
«E se» (scenário planning): + 50% para o tráfego às 19: 00-22: 00; A queda do provedor A → a redistribuição para B (+ 30% para a latência).
Real-time de ajuste: nowcasting por lid-métricas (animação das sessões, fila para o jogo, cestas).

5) Modelo de frase: onde «quebra» cadeia

Linha de montagem da consulta: Edge/CDN → L7-balanceador → aplicativo → kesh → BB → API externa → fila/pneu → processadores/ETL.

• Capacidade (CU/instância), escalabilidade (horizonte ./vertical.) , limites (conectórios, pps, iOPS), atrasos.
• Políticas de rejeição (rate limit, circuito breaker, degradação).
• SLO local e sua contribuição para e2e-SLO.

6) Reserva e orçamento de erros

Vinculando o headroom a um erro budet: menos orçamento → mais reserva.
Para os fluxos críticos (pagamento/comprovação) - headroom superior, para os fluxos secundários, abaixo.
Reservas frias/quentes: ativáveis no pico/acidente.

7) Escala: tática

HPA (por métricas de carga): RPS, latency, comprimento de fila, SLIs personalizados (better than CPU%).
VPA: correção de recursos para alimento (cuidado com o stateful e p99 GC).
Adaptadores KEDA/KEDA: zoom por fontes externas (Kafka lag, Redis list length, CloudQueue depth).
Warm pools/aquecimento - instâncias pré-levantadas para evitar início frio.
A abordagem «Load-as-Code»: as políticas de skale automático/limites/temporizações/retrações são versionadas e revisadas.

8) Filas, backpressure e controle de cauda

O objetivo é evitar que o p99 cresça de avalanche.
Limitamos o paralelismo e o tamanho da fila, introduzindo janelas de tempo e idempotidade.
Hedging/Retry-boodget: limite o orçamento total do usuário e do sistema.
Graceful degradation: desativação de fichas secundárias quando sobrecarregada.

9) BD, cajus e armazém

BD: limite de conexões, registro/FSync, índices, plano de solicitação, replica dag, hot-keys/tabelas, max TPS para transações.
Keshi: hit-ratio por segmentos, «tempestade de falhas» no lançamento/deficiência, distribuição de chaves.
Storaj: IOPS/throughput, atrasos, compressão, TTL, limpeza de partituras antigas/snapshots.
Esquema de migração: expand→migrate→contract sem bloqueios.

10) Fluxos de eventos e ETL

Kafka/pneu: largura de banda de partituras, lag, ISR, competition, limites de produtores/consoadores.
ETL/batchi: janelas de lançamento, orçamentos de tempo de execução, efeitos sobre o estorão de prod (throttle I/O).
Idempotidade e exactly-once-like para flow críticos (pagamentos/balanços).

11) Rede e perímetro

L4/L7 balanceadores: connation limits, syn backlog, TLS offload, sessão reuse.
CDN/Edge: largura de banda, política de dinheiro para reduzir a carga de trabalho de origin.
Limites Introspectivos: pps/mbps em VPC/Subrede, Valor Egress (FinOps).

12) Multiregião, DR. e jurisdição

Estratégias: ativo-ativo (GSLB/Anycast), ativo-passive (quente/quente/frio DR.).
N + 1 por região: suportar a perda de AZ/região, mantendo os fluxos core SLO.
Localização legal: divisão de tráfego/dados por país, limites diferentes e SLO por provedores.
Testes de DR.: game-days regulares com transferência de carga real.

13) Provedores externos: quotas e rotas

Pagamentos/KYC/antifrod/correio/SMS: quotas TPS, burst, limites diários.
Moultain Provedor: Rotação por Laticínio/Sucesso, SLO per Provedor, Failover automático.
Contratos SLA: conformidade e2e-SLO, canais de escalada, status de webhooks.

14) FinOps: custo e eficiência

TCO: compute + armazenamento + rede egress + licenças/provedores + serviço.
Unit Economics: valor de 1k solicitações/1 depósito/1 KYC.
Otimização: right-sizing, spot/descontos de prefixo, cachê de dinheiro, guia/traçado, níveis de armazenamento frios.
Transferência de carga no tempo: batches não críticos para janelas noturnas e regiões baratas.

15) Dashboards e relatórios (conjunto mínimo)

• Carga atual vs throughput resistente por elos.
• Headroom por serviços e regiões; previsão para 24/72 horas.
• KPI FinOps: $/1k solicitações, $/depósito.

• Alta estreita (p99, saturação, lag), reserva por DR..

• Sucesso/latência e limites dos provedores; A parte do tráfego nas rotas.

• Plano de upgrades/índices/otimizações, economia prevista/crescimento da capacidade.

16) Processos e papéis

RACI: Plataforma (infra/cluster/balanceadores), BD/Dados (índices, replicações), Comandos de Serviços (Perfis/Dinheiro), SRE (SLO, Alerts), Sec/Compliance (Cripto/Revistas), Finanças (Orçamento).
Ritmo: capacity-review semanal (mapa de trânsito, previsão, riscos), resumos FinOps mensais, testes DR trimestrais.
Mudar Management: grandes campanhas/lançamentos são capacity-gate (lista de cheques abaixo).

17) Folha de cheque de lançamento e campanha (capacity-gate)

• Previsão de carga para o pico e «+ x% cauda de emergência».
• Headroom disponível para core-stream (pagamentos/CUS/login).
• Os provedores têm quotas confirmadas; rotas alternativas estão ativas.
• HPA/KEDA liminares e warm-pool estão configurados.
• Filas/limites e degradação verificados (playbooks prontos).
• As partes canárias e o recuo automático estão incluídos.
• Os dashboards/alertas (burn-rate, saturation, p99) foram testados.
• O plano DR. e os contatos de escaladas são válidos.

18) Anti-pattern

«CPU <70% - tudo bem»: ignorar limites de dependência (conectórios de base de dados, iops, filas).
Uma caixa preta centralizada sem métricas per-elo é impossível saber onde está o limite.
Falta de estratégia em dinheiro - falhas de lançamento matam origin.
Hardcod limites de retrações sem orçamento é uma tempestade de pedidos.
Um provedor de pagamentos é um ponto de falha no pico.
Ignorar reservas quentes é um começo frio como causa de incidentes.
Não há testes DR intermitentes. O plano não funciona quando precisa dele.

19) Mini-calculação (exemplo)

Serviço X: de forma sustentável 350 RPS por pod (vCPU=1, RAM = 2 GiB). O objetivo é 5 000 RPS, headroom 25%.
Potência necessária = '5000/0. 75 = 6667 RPS`.
Podov = 'ceil (6667/350) = 20'. Mais um warm-pool de 15% → mais 3 pod.
BD: limite de 12k TPS, crédito atual 9k TPS, previsão de pico 10. 5k TPS → estoque 1. 5k (14%). É necessário: índice/charding/réplica ou armazenamento em dinheiro para 8. 5k.
Provedor A (KYC): quota de 120 rps, pico de 95 rps, campanha + 40% → 133 rps> quotas → routagem de 70% A/30% B.

20) Modelo de implantação de capacity planning

1. Descrever o caminho e2e e estreitos.
2. Digite CU e mede throughput sustentável de cada camada.
3. Configure as métricas saturation e p99 em todos os eixos.
4. Formar um calendário de eventos/campanhas/lançamentos.
5. Fazer uma previsão de cômodos e cenários.
6. Fixar headroom per-stream e per-região (referência a error budget).
7. Configure HPA/VPA/KEDA + warm-pools, limites/retais/filas.
8. Verificar as quotas de provimento, incluir as rotas multi.
9. Recolher dashboards e ritmo de capacity-review semanal.
10. Trimestralmente - ensinamentos DR. e revisão do modelo.

21) Total

O planejamento de capacidade é uma conexão controlada de previsões, limitações arquitetônicas e custos, em vez de «adicionar CPU». Quando cada camada do caminho e2e tem a capacidade medida, e o headroom e as estratégias de degradação estão associados com o SLO e o error budget, as cargas de pico, campanhas e acidentes deixam de ser uma surpresa. Esta abordagem reduz o risco de incidentes, estabiliza as métricas de negócios e otimiza os custos.