Operações e Gerenciamento → Escala de infraestrutura operacional

Escala de infraestrutura operacional

1) Porquê e o que considerar «zoom»

A escala é a capacidade da plataforma de aumentar a largura de banda (RPS/TPS, conectórios, IOPS, throughput) e a quantidade de dados sem perda de SLO e com custo controlado. Para o iGaming/fintech é diretamente sobre dinheiro, conversão de depósitos/apostas, jogos ao vivo e cálculos.

• Mantenha o SLO com um aumento X vezes maior de carga e picos sazonais.
• Forneça tempo de escala previsível (minutos, not hours).
• Manter a economia: custo/RPS, custo/transação, custo/1k eventos.

2) Princípios de plataforma escalável

1. Horizontal-primeiro: divisão em serviços menores, estateless; estado - em clusters de dados.
2. Back-pressure e filas: suavização de picos, proteção contra «tempestades».
3. Armazenamento em dinheiro em todas as camadas: cliente/edge/serviço/BD.
4. Idempotidade e repetibilidade: retais seguros, outbox, dedups.
5. Dependências com restrições: temporizadores, breakers, bulkhead-isolamento, rate-limits.
6. Observabilidade por sinais de capacidade: headroom, p95/p99, lag, conectórios, quotas.
7. Escalagem automática com HPA/VPA/Cluster Autoscaler + pares.
8. Multi-region by design: áreas blast independentes, dados locais, feelowers sustentáveis.

3) Capacity planning: como «contar quantas vezes você precisa»

Entradas de modelo: TPS de pico de destino, perfil de tráfego por hora, «caminhos críticos», coeficientes de disco em dinheiro, média payload's, SLO e limites de provedores.

• RPS → CPU/pod: 'pods = RPS p99 _ time/efetivo _ CPU _ em _ pol' (com 30-50% de reserva).
• Filas: 'velocidade _ mínima _ consumer ≥ velocidade _ pico _ de _ produtor 1. 2`.
• Conectores DB: 'max _ conns = serviços _ pool _ ativos _ média _ pool _ size 1. 3`.
• Castelo: tamanho = «hot working-set em N minutos» + 20-30% de reserva.
• Egress/CDN: pico egress = pico de solicitação média de resposta (considerem a compressão).

Headroom: meta 20-40% no pico (camadas). Abaixo de 15% → o desencadeador «capacity uplift».

4) Camadas e pattern de zoom

4. 1 Edge / CDN / WAF

Armazenamento em caixa (TTL + SWR), balanço geo, compressão, HTTP/2/3.
Rate-limits no perímetro IP/JWT/chave, proteção contra picos.
Fã-out eventos (jackpots, avisos ao vivo) através de corretores/canais pub/sub.

4. 2 passarela API/Backend-for-Frontend

Zoom horizontal por camadas estatais, dedicated pools por downstream.
HPA em métricas de negócios: RPS, p99, fila na bala de work - não apenas CPU.

4. 3 Filas asinhrônicas/streaming (Kafka/Rabbit/Pulsar)

Zoom por partituras e consoantes; evitar skew (chaves e distribuição).
Lag-alerts + escalonamento automático dos consórcios; DLQ e retry topics.
Retenção por SLA reconsilização e replay.

4. 4 Cash (Redis/Memcached)

Modos de cluster, réplicas, políticas de evicção (LFU), multiplet, pipeline.
Separação hot-key's e tarefas de fundo, limites de clientes e max-memory policy.

4. 5 Bancos de dados

Réplicas de read e roteamento de leitura, conexion pooling.
Charding por região/tenante/faixa de chaves.
CQRS: gravações para assistente/líder, leituras para réplicas.
Indexação e boat-screen workflow (outbox → stream → sink).
Arquivamento e dados quentes/frios (tiering).

4. 6 Armazéns de arquivos/objetos

Multiplicidade, download multipart, CDN-front, transformações asincrônicas.
As quotas do provedor, a limpeza das caudas e o orçamento do egress.

4. 7 Provedores (PSP/KYC/estúdios)

Multi-vendedor e roteirização por quotas/SLO/valor.
Circuito breaker + rate-limit para cada provedor, fila de retais, modos grace.

5) Zoom automático e gard rail

• HPA: метрики `rps_per_pod`, `queue_depth`, `p99_latency`; `targetAverageValue`.
• VPA: recomendação de recursos; atualizar fora do pico.
• Cluster Autoscaler: perfis de grupo de nod (spot + on-demand) com prioridades.
• PodDisruptionBudget/ TopologySpreadConstraints: uniformidade por zona.
• Protecção contra os bêbados.

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler spec:
scaleTargetRef: {apiVersion: apps/v1, kind: Deployment, name: api-gw}
minReplicas: 8 maxReplicas: 200 metrics:
- type: Pods pods:
metric:
name: rps_per_pod target:
type: AverageValue averageValue: "120"
- type: Pods pods:
metric:
name: p99_latency_ms target:
type: AverageValue averageValue: "280"
behavior:
scaleUp:
stabilizationWindowSeconds: 90 scaleDown:
stabilizationWindowSeconds: 300

• «Pause & Rollback» se o canário p99> 1. 3 x baseline 10 minutos.
• «Freeze scale-down» em horário nobre, apenas scale-up.
• «Stop retries» em 'open _ circuito = 1' a pontos estreitos.

6) Multi-region: ativo/ativo e ativo/passivo

Regiões isoladas Blast: clusters independentes, segredos locais/quotas.
Roteiro global: latency-/geo-based, health-protes, override manual.

• Quentes - local + eventual replicação (striptease).
• Transações críticas - Concordância de domínio (ledger/balanço).
• Playbooks Failover: mudança passo a passo da fonte, TTL, aquecimento de dinheiro.
• Regulamento de Exercício (DR): treinos trimestrais com objetivos RTO/RPO.

7) Pattern de rede e serviços

Serviço Mesh: mTLS, retry/breaker, outlyer detation, para-downstream limites.
eBPF/Observability em L4/L7, limites de conexão, proteção contra head-of-line.
Entrada API interna para S2S, rate-limit compartilhado e auditoria.
VPC/sub-redes de área blast, controle NAT/Egress, peering com vendedores.

8) Desempenho: testes e provas

Load & stress para o perfil de horário nobre + worst-case.
Soak (longo) - fugas de memória/descriptor, crescimento latency.
Chaos/game-days: queda do corretor/provedor/área, «provedor lento».
Perf regressão em CI: conjunto de cenários de referência e gates automáticos.

9) Dados e armazenamento: estratégias de crescimento

Altura vertical para «teto» horizontal/charding.
Leituras → réplicas/dinheiro; gravações → batchi/asinhron/registro.
Migração de diagramas: expand → migrate → contract, sem bloqueios globais.
Arquivamento: Partituras frias em armazenamento barato + on-demand-re-hidração.
Pesquisa: índices individuais (OpenSearch/Solr) com pipline de atualizações incorporativas.

10) Gerenciamento de provedores e quotas

Cartão de quotas (TPS, janelas, valor); alert 'usage _ ratio> 0. 9`.
Routing em custo/qualidade (smart roting).
Acordos OLA ↔ SLO e processo de elevação de quotas.
Um pool de alternativas e uma mudança quente.

11) Observabilidade e sinais de escala

• Capacity headroom по слоям; `queue_lag/backlog growth`; `kafka ISR`; `db connections`/`repl lag`; `redis evictions`; `open_circuit`/`retry_rate`; `quota_usage`.
• Métricas de negócios: sucess rate/conversão de depósito, hora de iniciar o jogo.
• Custo: custo/RPS, vale/1k calls.

• Capacity Overview (headroom, alto risco, burn-rate SLO).
• Stream & Queue Panel (lag/backlog, consumer saturation).
• DB & Cachê (p99, conectórios, hit/evictions).
• Provers & Cotas (TPS, timeouts, custo, mudanças).
• Mudança Safety (antes/depois do lançamento, canário, auto-gates).

ALERT HeadroomLowAPI
IF capacity_headroom{layer="api"} < 0. 15 FOR 10m

ALERT KafkaBacklogAtRisk
IF (consumer_lag > 5e6 AND rate(consumer_lag[5m]) > 5e4) AND (hpa_desired == hpa_max) FOR 10m

ALERT DBConnectionsNearMax
IF active_conns / max_conns > 0. 85 FOR 5m

ALERT ProviderQuota90
IF usage_quota_ratio > 0. 9 FOR 5m

12) FinOps: Dimensionar é vantajoso

Coeficientes de eficiência: custo/RPS, custo/depósito, custo/1k eventos.
Right-sizing: VPA/recomendações, relatórios de «over-provisioned».
Spot/Preemptible para não-crítico; Reserved/Committed para carga básica.
Orçamento e cachê egress, CDN/edge-obload.
Recolha e arquiva os logs de valor (hot vs cold).
Quotas de advertência (soft-cap) e tíquetes automáticos para expansão.

13) Processos e pessoas

Mudança Management: Canários, ficheflags, paragens de regressão.
Incidente de preparação: runbook 'e' onde adicionar capacidade ',' como mudar de região '.
Planejamento de picos: calendário de jogos/torneios/campanhas e janelas de provedores.
Game-days regulares e ensinamentos DR.
Matriz de propriedade: quem pode apertar botão para o feelover/aumentar quotas.

14) Folhas de cheque de implementação

• Mapa de caminhos críticos e limites (por camadas), objetivo headroom ≥ 30%.
• HPA para métricas de negócios + Cluster Autoscaler; PDB/SpreadConstraints.
• Filas em caminhos quentes, idempotency-keys, outbox.
• Caches: objetivos hit ≥ 90%, políticas evictions, índices-chave.
• DB: réplicas read, pool de conectórios, plano de charding.
• Provedores: multi-vendedor, quotas, breakers/retais.
• Dashboards «Capacity/Stream/DB/Providers», alertas do parágrafo 11.
• Canário e auto-gates «antes/depois do lançamento».
• Dr. playbook e um feedback parcial.

• Aquecer com o dinheiro, pré-scail HPA/ASG, warm-standby frases.
• Aumentar as quotas dos provedores, incluir smart-routing.
• Incluir o modo night de supressão para alertas não ríticas.
• O «modo safe» está pronto para ser ativado instantaneamente.

15) Anti-pattern

O upgrade vertical é «até» em vez de horizontal.
Um pool de fluxo/conexões compartilhado em todos os downstream (head-of-line).
Retraias em temporais estreitos, falta de jitter → tempestade.
Não há histerese em alertas e políticas scale.
Uma base de dados global sem charding ou localização.
Fé cega em vendedor SDK sem controle de temporizações/retrações/observabilidade.
Falta de ensinamentos de DR., o feelover «só no papel».

16) KPI de escalabilidade

Cumprimento SLO no pico (p95/p99, sucess rate).
Headroom por camadas em horário nobre.
MTTS (Mean Time To Scale) - até que recursos adicionais apareçam.
Backlog/Lag Resolution Time - hora em que as filas são batidas após o pico.
Mudar Failure Rate para um período de crescimento ativo.
Costa/RPS e poupança de dinheiro/CDN/edge-obload.
DR. Readiness: RTO/RPO em exercícios.

17) Exemplos de modelos «rápidos»

partitions(topic="bets") = ceil(peak_msgs_per_sec / target_msgs_per_partition)
consumers = min(partitions, max_pods); rebalance_on: skew > 1. 5x scale_up_if: lag > 5e5 && rate(lag[5m]) > 5e4

max_connections = poolers pool_size 1. 3 read_routing: primary (write), replicas (read majority)
shard_key: tenant_id or region_id

maxmemory-policy: allkeys-lfu cluster-replicas: 1 evict-alert: rate(evictions[5m]) > 0 && used_mem/limit > 0. 8

guardrails:
- metric: api_p99_ms, threshold: 1. 3 baseline_1d, window: 10m, action: pause_and_rollback
- metric: error_rate, threshold: 2 baseline_1d, window: 5m, action: pause max_step: 10%
step_interval: 15m

18) FAQ

O que fazer primeiro?
A: Estreitos de acordo com dashboards: filas/cachês/leitura de BD. Caminhos quentes (depósito/aposta/lançamento do jogo) - prioridade.

Como compreender que a escala automática «torna pior»?
A: Veja a correlação: escale- up↑, e p99/erros não melhoram - talvez você esteja «escalando o problema» (downstream estreito/quota). Acesse breakers/degradação.

Precisamos sempre de um segundo provedor?
Para caminhos críticos, sim. De outra forma, pelo menos um «estilo safe» com um guião simplificado e um cachê.

Q: Active-active или active-passive?
A: Se os requisitos RTO são baixos e muitos jogadores regionais - ativo-ativo. Caso contrário, comece com um failover ativo-passive.