Aree di disponibilità e regioni crociate

1) Termini e obiettivi

Area di disponibilità (AZ) - Centro dati isolato all'interno della regione (potenza/rete).
La regione è un gruppo AZ con geografia generale e ritardi.

• RTO - Per quanto tempo è possibile non fornire il servizio.
• RPO - Quale quantità di dati è possibile perdere.

Di solito, all'interno della regione, prendiamo di mira RTO 5-15 min, RPO} 0-1 min, interregionale RTO 1 h, RPO 5 min (dipende dal prodotto e dal budget).

2) Modelli architettonici

2. 1 All'interno della regione (multi-AZ)

Livello stateless - Distribuito in AZ; bilanciamento - L4/L7 con health-checks.
Livello Stateful - Cluster con replica sincrona (o quorum) tra AZ.
Cache/code: cluster, con scardinamento AZ e failover automatico.

2. 2 Interregionale (multi-region)

Active-Active: entrambe le regioni ricevono traffico.

Latitanza minima per gli utenti, ripristino rapido, complessità di consistenza e conflitti.
Active-Passive (hot/warm) - La regione principale serve, la seconda in attesa calda/calda.

dati più semplici, meno costosi, - più alto di RTO.
Pilot-Light - Luce minima (i dati vengono sincronizzati e i calcoli vengono espansi in caso di incidente).
DR-backup: solo backup e script di ripristino (il più economico e il più lento).

3) Dati e consistenza

3. 1 Database

Quorum sincrono (RPO≈0, ↑latentnost): PostgreSQL con standbys sincronizzati all'interno della regione; Database distribuiti (CockroachDB/Cassandra) con quorum locali (Locale Quorum) e bilanciamento AZ.
Replica interregionale asincrona (RPO> 0, ↓latentnost): replica logica Postgres/MySQL. «global tables» в KV/NoSQL; CDC→strim in un'altra regione.
Record in conflitto: per active-active, utilizzare CRDT/versioning o la strategia «origine verità» (leader-region per key/tenant).

3. 2 Event-sorsing e code

Code/striam (Kafka/Pulsar/SQS-simili): mirror-topics o replicatori crocifissi-regionali; la chiave è l'idimpotenza dei concittadini e il dedotto delle chiavi.
Webhook e partner esterni: firmare, avere replay, memorizzare offset/checkpoint in entrambe le zone.

3. 3 Cache

Cache locale per-regione (write-through/refresh-ahead) cache condivisa globale solo per KV resistenti (altrimenti split-brain). Disabili per eventi (pub/sub), TTL è conservativo.

4) Traffico globale e tracciato di rete

GSLB/DNS: Geo-/Latency-based routing, health-checks, traffic-weights per canarini e incidenti.
Anycast/Edge: avviciniamo l'accesso all'utente e poi alla regione sana più vicina.
Criteri Failover: pool regionali upstream ov, divieto 0-RTT su percorsi critici, minimi timeout a dipendenze interregionali.
Policy retraes: backoff esponenziale + jitter, limitazione total-deadline, idipotente PUT/POST con'Idempotency-Key '.

5) Kubernets e servizio-mesh

5. 1 Multi-AZ in un unico cluster

topology spread constraints по `topology. kubernetes. io/zone`.
PodDisruptionBudget и priority classes.
NodeAffinity/Anti-Affinity - Evitare la posizione delle repliche.
Aree di storage: PV con replica AZ o sistemi volume distribuiti.

5. 2 Multi-region (multi-cluster)

Cluster separati per regione + GitOps (Argo CD/Flux) per sincronizzazione dichiarativa.
Servizio Mesh (Istio/Linkerd): locality-aware load-balancing e failover tra le regioni mTLS, identità comune.
Traffic-shifting: 1%→10%→50% per la nuova regione; maniglia 0% immediata.

6) Selezione RTO/RPO e mappatura dei pattern

7) Test di disponibilità (DR)

GameDays: uno scenario su larga scala trimestrale «disattivato regione/AZ».
Iniezioni Chaos: ritardi di rete, pacchetti persi, disattivazione broker/base in una AZ.
RTO/RPO effettivo: misura il tempo di cambio e la perdita dei dati, pubblica il report.
Runbooks - Istruzioni passo-passo e pulsanti rossi per i passaggi (DNS weights, feature-flags, disattivazione dei file pesanti).

8) Osservabilità e controllo

Tagli di metriche per region/AZ/tenant; p95/p99 di latitanza lungo le rotte.
SLO e Errore Budget per la regione e per il pool globale.
Il degrado di una regione non dovrebbe «silenziare» il cercapersone se l'altra porta il traffico nella norma.
Трейсы: baggage `region`, `az`, `failover=true/false`; report «quante richieste sono state richieste per failover».

9) Sicurezza e conformità

Data residency: allega i dati di pagamento PII a determinate regioni (giurisdizione).
Segreti: KMS/Smart HSM con chiavi e rotazione cross-regionali; Separare il materiale delle chiavi per-regione.
mTLS e fiducia reciproca tra le regioni; limitare gli egress regionali all'ACL.

10) Costi e risparmi

Edge cache + SWR - Riduzione dell'egress interregionale.
Diverse classi di storage (hot/warm/cold) e downsampling metriche/logi.
Profili auto-scale per regione (minimo notturno).
Identità immagine + configurazione differenziata tramite variabili ambiente/Helm values.

11) Antipattern

Uno Stateful-Master per tutto il sistema; split-brain senza quorum.
Scrittura sincrona interregionale nell'unico RDBMS (latitanza insostenibile).
Cache globale con una forte consistenza senza CRDT: blocchi e fantasmi.
I retrai senza idepotenza sono stati duplicati da transazioni/pagamenti.
Un unico SLO «globale» nasconde il fallimento di una regione.
Niente esercitazioni DR regolari. I piani non funzionano in battaglia.

12) Specificità iGaming/finanza

I provider di pagamento/CUS sono selezionati a livello regionale; fare smart-routing su PSP con segnali health, failover su riserva.
Giurisdizione: conservazione del PII e dei registri delle transazioni in un paese/regione; crociera - solo aggregazioni/anonimi.
Limiti/gioco responsabile: regole e orologi locali - Non replicare «in testa» tra le regioni, utilizzare la consistenza degli eventi.
Bonus/bilanci: chiavi idipotenti e «fonte di verità» per tenant/region; reconcile-jobs dopo DR.

13) Mini-ricette (pseudonfigi)

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 DNS feelover di peso (idea)

«weight (eu) = 90», «weight (us) = 10» in caso di degrado «eu» si sposta automaticamente in «us». Health-checks e TTL ridotti (ma non troppo aggressivi, 30-120 s).

14) Foglio di assegno prod

• Definito RTO/RPO per il servizio e concordato con il business.
• Stateless distribuito in AZ; stateful ha un quorum/replica e un modello comprensibile di consistenza.
• Replica interregionale (asincrone/CDC), test di conflitto/deduplicatore.
• GSLB/Anycast sono configurati, health-checks e weights sono automatizzati.
• Kubernetes: topology-spread, PDB, anti-affinity; multi-cluster GitOps.
• Retrai con jitter, idempotenza su write; brevi timeout interregionali.
• esercizi DR, RTO/RPO effettivi misurati; runbook aggiornato.
• Osservazione di region/AZ, SLO e burn-rate su tagli, gli alert non «silenziano» il normale funzionamento.
• Data residency/segreti/chiavi corrispondono alla regolazione.
• Economia: egress, memorizzazione, profili di scale automatico sotto controllo.

15) TL; DR

Costruisci multi-AZ come livello base, multi-region come assicurazione aziendale. Selezionare il pattern (active-active/standby) sotto RTO/RPO e il costo, replicare i dati consapevolmente (quorum/CDC/CRDT), gestire il traffico globale tramite GSLB/Anycast e locality-aware bilanciamento. Obbligatori: idempotenza, brevi timeout, esercitazioni DR regolari, SLO/metriche sui tagli region/AZ. Per iGaming/Finanza, aggiungere PSP/KYC regionali, requisiti di dati e SLO separati per giurisdizione.