Áreas de disponibilidade e regiões cruzadas

1) Termos e objetivos

A área de disponibilidade (AZ) é um centro de dados isolado dentro da região (sua própria capacidade/rede).
A região é um grupo AZ com geografia geral e atrasos.

• RTO (Recovery Time Objectiva) - Quanto tempo é possível não fornecer o serviço.
• RPO (Recovery Point Objectiva) - Qual quantidade de dados pode ser perdida.

Normalmente, dentro da região visamos RTO ≤ 5-15 min, RPO £0-1 min, interregionalmente RTO ≤ 1 h, RPO ≤ 5 min (dependente do produto e orçamento).

2) Modelos arquitetônicos

2. 1 Dentro da região (multi-AZ)

Camada estateless: distribuído em AZ; balanceamento - L4/L7 com health-checks.
Camada stateful: clusters com replicação sincronizada (ou quórum) entre AZ.
Cash/filas: cluster, com charding AZ e failover automático.

2. 2 Interregional (multi-region)

Ativo-ativo: ambas as regiões recebem tráfego.

latência mínima aos usuários, recuperação rápida, complexidade de consistência e conflitos.
Ative-Passive (hot/warm): A região principal serve, e a segunda, espera quente/quente.

dados mais fáceis, mais baratos; - acima de RTO.
Pilot-Light: «luz» mínima (os dados são sincronizados e os cálculos se desenvolvem quando o acidente acontece).
Dr.-backup: apenas bacapes e cenário de recuperação (o mais barato e o mais lento).

3) Dados e consistência

3. 1 Bancos de dados

Quórum sincronizado (RPO≈0, ↑latentnost): PostgreSQL com standbys sincronizados dentro da região; BD (CockroachDB/Cassandra) distribuídos com quórum local (Local Quorum) e balanceamento AZ.
Asincrona interregional (RPO> 0, ↓latentnost): replicação lógica de Postgres/MySQL; «global tables» в KV/NoSQL; CDC→strim para outra região.
Gravações conflitantes: Para ativo, use CRDT/versioning ou estratégia de origem da verdade (líder-region per key/tenant).

3. 2 Event-sorsing e filas

Filas/striptease (Kafka/Pulsar/SQS-similares): mirror-topics ou replicadores cruzados-regionais; a chave é a idimpotência dos consoadores e o dedão das chaves.
Webhooks e parceiros externos: assinar, ter replay, armazenar offset/checkpoint em ambas as zonas.

3. 3 Cash

Cachês locais para-região (write-through/refresh-ahead); apenas para KV resistentes (caso contrário, split-brain). Deficiente por evento (pub/sub), TTL é conservador.

4) Tráfego global e circuito de rede

GSLB/DNS: Geo-/Latency-based roting, health-checks, traffic-weights para canarinhos e acidentes.
Anycast/Edge: Aproximamos a entrada do usuário e, a seguir, a região saudável mais próxima.
Políticas Failover: pula regional upstream's, proibição 0-PTT em vias críticas, tempo baixo para dependências inter-regionais.
Políticas de retrações: backoff exponencial + jitter, limitação total-deadline, idumpotentes PUT/POST com 'Idempotency-Key'.

5) Kubernetes e serviço-mesh

5. 1 Multi-AZ em um único cluster

topology spread constraints по `topology. kubernetes. io/zone`.
PodDisruptionBudget и priority classes.
NodeAffinity/Anti-Affinity - evitar a localização de réplicas.
Áreas de armazenamento: PV replicado por AZ ou sistemas de volume distribuídos.

5. 2 Multi-region (multi-cluster)

Clusters para-região + GitOps (Argo CD/Flux) separados para sincronização declaratória.
Serviço Mesh (Istio/Linkerd): locality-aware load-balancing e failover entre as regiões; mTLS, uma identidade comum.
Traffic-shifting: gradativamente 1%→10%→50% para a nova região; caneta «colocar 0%» instantaneamente.

6) Seleção de RTO/RPO e referência a patterns

7) Testes de resistência a falhas (DR)

GameDays: Cenário de grande escala trimestral «apagado região/AZ».
Chaos-injeções: atrasos de rede, perdas de pacotes, desativação de corretor/base em um AZ.
RTO/RPO real: Medam o tempo de mudança e a perda de dados, e publiquem o relatório.
Runbooks: instruções passo a passo e «botões vermelhos» para alternar (DNS weights, função-flags, desativação de fichas pesadas).

8) Observabilidade e controle

Cortes de métricas por region/AZ/tenant; p95/p99 latência sobre rotas.
SLO e Erro Budets para a região e para o pool global.
Alerts, a degradação de uma região não deve «silenciar» o paging se o outro tiver tráfego normal.
Трейсы: baggage `region`, `az`, `failover=true/false`; relatórios «quantas solicitações foram feitas por failover».

9) Segurança e conformidade

Data residency: vinculação de dados de pagamento PII a determinadas regiões (jurisdição).
Segredos: KMS/HSM inteligente com chaves cruzadas e rotativo; Separa os materiais das chaves por-região.
mTLS e confiança mútua entre as regiões; limite os egress cruzados por LCA.

10) Custo e economia

Edge-dinheiro + SWR - redução do egress interregional.
Diferentes classes de armazenamento (hot/warm/cold) e downsampling métricas/logs.
Perfis auto-scale por região (mínimo noturno).
Identidade de imagem + configuração diferenciada através de variáveis de ambiente/Helm values.

11) Antipattern

Um Stateful-mestre para todo o sistema; split-brain sem quórum.
Gravação sincronizada interregional em RDBMS único (latência insustentável).
O dinheiro global com forte consistência sem CRDT → bloqueios e «fantasmas».
Retraias sem idempotidade → transações/pagamentos duplicados.
Um único SLO global esconde o fracasso de uma região.
Não há exercícios DR regulares. Os planos são inoperantes.

12) Especificidades do iGaming/Finanças

Provedores de pagamento/CUS são escolhidos regionalmente; faça smart-routing por PSP com sinais health, failover por reserva.
Jurisdição: armazenamento de PII e registros de transações dentro de um país/região; Região Cruzada - apenas máquinas/anónimo.
Limites/jogo responsável: regras e relógios locais - Não replique «de frente» entre as regiões, use consistência de eventos.
Bónus/balanço: chaves idumpotentes e «fonte da verdade» per tenant/region; recôncil-jobs depois do DR..

13) Mini-receitas (pseudoconfigs)

13. 1 Envoy locality-aware + failover

yaml load_assignment:
endpoints:
- locality: { region: eu, zone: eu-a }
lb_endpoints: [{ endpoint: { address:... } }]
- locality: { region: eu, zone: eu-b }
lb_endpoints: [{ endpoint: { address:... } }]
- locality: { region: us, zone: us-a } # failover target lb_endpoints: [{ endpoint: { address:... } }]
common_lb_config:
zone_aware_lb_config: {}
locality_weighted_lb_config: {}
outlier_detection:
consecutive_5xx: 5 base_ejection_time: 30s

13. 2 Kubernetes topology spread

yaml spec:
topologySpreadConstraints:
- maxSkew: 1 topologyKey: topology. kubernetes. io/zone whenUnsatisfiable: DoNotSchedule labelSelector: { matchLabels: { app: api } }

13. 3 fones de peso DNS (ideia)

'weight (eu) = 90', 'weight (us) = 10' → ao degradar 'eu' automaticamente para 'us'. Health-checks e TTL reduzidos (mas não muito agressivo, 30-120 s).

14) Folha de cheque pró-prontidão

• Definidos RTO/RPO per serviço e alinhados com o negócio.
• O Stateless está distribuído por AZ; O stateful tem quórum/replicação e um modelo compreensível de consistência.
• Replicação interregional (asinhron/CDC), testes de conflito/dedução.
• GSLB/Anycast configurados, health-checks e weights automatizados.
• Kubernetes: topology-spread, PDB, anti-affinity; multi-cluster GitOps.
• Retraí com jitter, idempotidade em write; Os tempos curtos são inter-regionais.
• Ensinamentos DR., RTO/RPO real medido; runbook atual.
• Observabilidade por region/AZ, SLO e burn-rate em corte, os alerts não «silenciam» o funcionamento normal.
• Data residency/segredos/chaves correspondem à regulação.
• Economia: egress, armazenamento, perfis de tela automática sob controle.

15) TL; DR

Construa multi-AZ como camada básica, multi-region como seguro de negócio. Selecione o pattern (ativo-ativo/standby) sob RTO/RPO e o custo, replique os dados conscientemente (quorum/CDC/CRDT), gerencie o tráfego global através do GSLB/Anycast e do balanceamento locality-aware. É obrigatório: idempotidade, curtos de tempo, exercícios DR regulares, SLO/métricas em cortes region/AZ. Para o iGaming/Finanças, adicione PSP/KYC regionais, requisitos de dados e SLO de jurisdição separados.