Tecnologia e Infraestrutura → Arquitetura em nuvem e SLA
Arquitetura em nuvem e SLA
1) Por que o SLA e como controlá-los
O SLA (Service Level Agreement) é uma promessa externa para os negócios/parceiros sobre a disponibilidade, velocidade e correção do serviço.
SLO (Service Level Objectiva) - Níveis de destino internos para comandos.
O SLI (Service Level Indicator) é uma métrica mensurável baseada no SLO.
O iGaming/Fintech é caracterizado por janelas rígidas de pico (torneios, apostas live, períodos de contabilidade, dias «salários»), forte dependência de provedores PSP/KYC e geografia. A SLA deve considerar este comportamento, e a arquitetura deve fornecer garantias não apenas médias, mas também percalços.
2) Terminologia básica
Disponibilidade (Availability) - Proporção de solicitações de sucesso por intervalo.
Latência - P50/P95/P99 para operações-chave.
Erro - Identifique com precisão (5xx, timeout, erro de negócio?).
RTO (Recovery Time Objectiva) - Quanto tempo é permitido para a recuperação.
RPO (Recovery Point Objectiva) - Quantos dados podem ser perdidos em um acidente.
Error Budet - 1 - SLO, «reserva» para alterações e incidentes.
3) Esqueleto de arquitetura na nuvem sob SLA
3. 1 Multi-AZ
Replicação de estado (BD, dinheiro, filas) para, no mínimo, 2-3 AZ.
Estandbay frio/quente, failover automático.
Balanceadores locais (L4/L7) com cheques health per-AZ.
3. 2 Multiregião
Ativo-ativo: RTO baixo/RPO, mais consistência e custo.
Ativo passivo (hot/warm): mais barato, RTO maior, mas mais fácil de controlar dados.
Roteiro geográfico (GeoDNS/Anycast), isolamento «blast radius».
3. 3 Armazéns e dados
BB transaccional: replicação sincronizada dentro da região, asíncrona interregional.
Cash: réplicas cruzadas regionais, modo «local reads + async warmup».
Armazenamento de objeto: versioning, ciclos life, cross-region reprodução.
Filas/streaming: clusters espelhados/fluxos multi-regionais.
3. 4 Isolamento de contornos
Separar serviços críticos (payments/wallet) e tarefas analíticas «pesadas».
Rate-limits/cotas entre os contornos para que os relatórios não «comam» a proda.
4) Pattern de alta disponibilidade
Bolkhead & Pool Isolation - Isolando poóis de conexões e recursos.
Circuito Breaker + Timeouts - Proteção contra as dependências de integração externa.
Idempotency - Repita os pedidos sem cancelamentos duplos.
Graceful Descradation - Ao degradar, desativamos os fichas nefundamentais (avatarcas, filtros avançados).
Backpressure - Controle o fluxo de entrada, não permita filas até o horizonte.
Chaos/Failure Inhation - «falhas» programadas para verificar hipóteses de confiabilidade.
5) Estratégias DR. (Disaster Recovery)
Escolha: pagamentos/carteira - mínimo Hot Standby; conteúdo/catálogo - Warm; relatórios - Backup & Restore com janelas claras.
6) Sobre o SLI/SLO: como medir a coisa certa
6. 1 SLI por nível
SLI cliente: end-to-end (incluindo gateway e provedores externos).
SLI de serviço: «puro» latidão/erros de serviço.
Business SLI: CR (registratsiya→depozit), T2W (time-to-wallet), PSP-decline rate.
6. 2 Exemplos de SLO
Disponibilidade Core API: ≥ 99. 95% em 30 dias.
Latitude payout-iniciação P95 ≤ 350 ms, P99 ≤ 700 ms.
Entrega de webhooks PSP: ≥ 99. 9% por 60 segundos (com retraias).
Dados Freshness relatórios: ≤ 10 min em 95% do tempo.
6. 3 Error Budget Policy
50% do orçamento são para mudanças (lançamentos/experiências) e 50% para incidentes.
Queima de orçamento, só estabilização.
7) Desempenho e zoom
HPA/VPA com SLO orientado (não só CPU, mas filas/latência).
Skeiling preditivo baseado em horários e picos históricos.
Warm pools/pré-aquecimento de conexões BD/PSP antes dos torneios.
Armazenamento e edge - Reduz o RPT, especialmente para catálogos de jogos e assets estáticos.
8) Camada de rede e tráfego global
Anycast/GeoDNS para minimizar a latência e a localização de acidentes.
Políticas de failover: health-in-região, liminares, «stickiness» com TTL.
mTLS/WAF/Rate Limit na borda, proteção contra tráfego de bot.
Controle Egress para PSP/KYC por allow-list e SLA-aware retais.
9) Dados e consistência
A escolha de nível de coerência é rigorosa (payments) vs eventual (catálogo/classificação).
CQRS para descarga de leitura e vertical de comandos críticos.
Outbox/Inbox para «exatamente um dia» entrega de eventos.
Migração sem downthame: expand-migrate-contract, gravação dupla durante as alterações MAJOR.
10) Observabilidade (Observabilidade) sob SLA
Trailers através da passarela: correlação 'trace _ id' com o parceiro/região/versão da API.
SLO-dashboards com burn-rate, «meteorologia» por região e provedores.
Alertas de sintomas, não de proxy (não CPU, mas R99/erro).
Synthetics: verificações externas dos países da meta (TR, BR, EU...).
Auditoria e relatórios: exportação de SLI/SLO para um portal de parceiros.
11) Segurança e Complacência
Segmentação de redes e gestão de segredo (KMS/Vault).
Criptografia em voo/em paz, toquenização PAN/PII.
Políticas de acesso de papéis para almirantes/operadoras.
Os logs são inalterados (WORM) e os retensivos de auditoria.
Regulação: armazenamento na região, relatórios, comprovação de cumprimento de SLA.
12) FinOps: SLA como controlador de custo
Aposte os preços das desonerações SLO, quanto vale + 0. 01% de disponibilidade?
Perfire as janelas de pico, sem inflar a potência constante.
Right-sizing e «spot onde você pode» para tarefas de fundo.
Quotas e orçamentos para contornos, não permita degradação «gratuita».
13) Testes de confiabilidade
GaDay/Chaos-sessões: desligamento de AZ/PSP, atrasos nas filas, quebras de BGP.
DR Drilly: treinamento regular para mudar de região com metas RTO.
Load & Soak: projeções de longa duração com perfis reais de apostas/torneios.
Os incidentes replay são uma biblioteca de feeds conhecidos e de reprodução.
14) Lado processual do SLA
Catálogo SLO, dono, fórmula, métricas, fontes, alertas.
Alterações por RFC/ADR: avaliação do impacto sobre o erro budet.
Pós-mórtemos: melhoria da arquitetura e dos ranbooks, ajustamento do SLO.
Comunicações com parceiros: correio, status, planned maintenance.
15) Exemplos de SLI/SLO/relatórios
15. 1 Fórmula
SLI_availability = (успешные_запросы / все_запросы) 100%
SLI_latency_P99 = перцентиль_99(латентность_запроса)
SLI_webhook_D+60 = доля вебхуков, доставленных ≤ 60 сек15. 2 Exemplo de conjunto de SLO para Core API
Disponibilidade (30 dias): 99. 95%
P95 endpoint '/v2/payouts/create ': ≤ 350 ms
Erros 5xx (deslizante 1h): <0. 3%
Webhook delivery ≤ 60 сек (P99): ≥ 99. 9%
RPO para carteira: ≤ 60 segundos, RTO ≤ 5 min
15. 3 Relatório da SLA (queimador)
Concluído: 99. 97% (SLO 99. 95%) +
Violações: 2 episódios na região BR devido a temporizações PSP (total de 8 min).
Medidas: adicionado smart-routing por códigos de falha, aumentado warm pool conexões PSP-B.
16) Folha de cheque de implementação
1. São definidos caminhos críticos do usuário e SLI correspondentes.
2. SLO para 30/90 dias + error budget policy.
3. Multimodalidade e plano DR. com objetivos RTO/RPO, driblados regularmente.
4. Synthetics de geo-alvo, dashboard per-region/per-PSP.
5. Pattern de estabilidade: circuito breaker, backpressure, idempotency.
6. Política de degradação e função flags para fichas desativadas.
7. FinOps: orçamentos de circuito, previsão de picos, warm pools.
8. Segurança: segmentação, criptografia, auditoria.
9. Documentação SLA para parceiros, processo de comunicação.
10. Retrospectivas e revisões SLO a cada 1 ou 2 trimestres.
17) Anti-pattern
Prometer SLA sem SLI mensurável e uma técnica de contagem transparente.
Considerar a disponibilidade «na entrada do serviço» ignorando o gateway/provedor.
Basear-se apenas na latência média, ignorando as caudas P99.
Dr. «em papel», falta de treino real.
Recursos «eternos» sem limites, um relatório a vazar.
Misture prod e análise pesada em um único cluster/BD.
18) Total
A arquitetura na nuvem sob SLA é uma combinação de patterns técnicos (multi-AZ/region, isolamento, dados de falha), processos (SLO, errante budet, DR.-drili) e economia (FinOps). Dê-se direito a falhas previstas: teste de resistência a falhas, mede por percentilos, limite o «raio explosivo» e comunique abertamente. Então, as promessas da SLA não serão marketing, mas engenharia gerida.