La lezione 73 ha scelto la forma dei servizi. La lezione 74 ha scelto la forma delle conversazioni tra di loro. Questa lezione sceglie la forma della geografia. Una volta che l’architettura è decisa e i workflow sono assestati, la prossima domanda che atterra sul tavolo del team è “cosa succede quando una delle nostre region va giù?” oppure “cosa succede quando i nostri utenti europei si lamentano che l’app è lenta?”. Entrambe le domande puntano alla stessa risposta: multi-region. Ed entrambe arrivano con un cartellino del prezzo che il team deve guardare in faccia onestamente prima di firmare.
Questa è la lezione che chiude l’apertura del Modulo 10. Dopo questa, il resto del modulo si volge alle preoccupazioni trasversali (sicurezza, costi, sostenibilità, integrazione dell’AI) che si appoggiano sopra qualunque forma il team abbia scelto. La geografia è l’ultima grande decisione architetturale prima che quelle preoccupazioni prendano il sopravvento.
Perché i team vanno in multi-region
I quattro motivi, grosso modo nell’ordine in cui spingono la maggior parte dei team oltre la linea:
Latenza. Gli utenti dall’altra parte del mondo sperimentano la latenza della velocità della luce, più la velocità reale della rete che è peggio. Una richiesta da Sydney a un data centre US-East è circa 200ms one-way prima ancora che l’applicazione faccia qualcosa. Per una singola pagina può essere tollerabile; per un’app chatty o qualsiasi cosa real-time non lo è. Servire gli utenti di Sydney da una region a Sydney riporta il round-trip a millisecondi a singola cifra.
Disaster recovery. Un’outage region-wide su uno qualunque dei major cloud capita. AWS US-East-1 ha avuto diverse outage da ore multiple nell’ultimo decennio. Azure ha avuto incidenti region-wide su DNS e storage. GCP ha avuto fallimenti del control plane. Quando l’intera region in cui vive il tuo prodotto è giù, “tornerà quando AWS torna” non è una risposta soddisfacente da dare al cliente che paga per uno SLA. Il multi-region con la capacità di fare failover è la difesa.
Compliance. GDPR (UE), CCPA (California), LGPD (Brasile), la Personal Information Protection Law (Cina) e una lista crescente di regolamentazioni regionali specificano dove i dati personali possono essere conservati ed elaborati. Lo stesso prodotto che spedisce a livello globale deve tenere i dati degli utenti europei nei data centre europei, a volte i dati degli utenti cinesi nei data centre cinesi, e a volte i dati degli utenti russi nei data centre russi. La compliance è il più assoluto dei motivi: non riguarda performance o disponibilità, riguarda se ti è consentito operare.
Capacità. Una piccola minoranza di prodotti supera la capacità di una singola region. Le cloud region sono grandi; questo caso è raro per la maggior parte dei team. Quando capita, la seconda region viene aggiunta perché la prima non riesce a reggere il carico.
I primi tre guidano la maggior parte dell’adozione del multi-region. Il quarto è un trigger reale ma poco comune.
Le tre forme di deployment
Una volta che il team ha deciso di andare multi-region, tre forme sono le scelte sul menu.
flowchart TD
subgraph AP[Active-Passive]
AP1[Primary Region<br/>serves all traffic]
AP2[Secondary Region<br/>standby, replicating]
AP1 -->|async replication| AP2
end
subgraph AA[Active-Active]
AA1[Region A<br/>serves traffic]
AA2[Region B<br/>serves traffic]
AA1 <-->|bidirectional replication| AA2
end
subgraph FS[Follow-the-Sun]
FS1[APAC Region<br/>serves during APAC hours]
FS2[EMEA Region<br/>serves during EMEA hours]
FS3[Americas Region<br/>serves during US hours]
FS1 -->|handoff| FS2
FS2 -->|handoff| FS3
FS3 -->|handoff| FS1
endActive-passive
La region primaria serve tutto il traffico. La region secondaria fa girare lo stesso stack, mantiene una replica dei dati, e per il resto è ferma. Quando la region primaria fallisce, il team (o un processo automatizzato) ribalta il DNS e la secondaria diventa la primaria. Questa è la forma tradizionale di disaster recovery, usata da molto prima che “multi-region” diventasse la frase di moda per descriverla.
I punti di forza:
- Operativamente più semplice. C’è una region che serve traffico per volta. I conflitti tra region non possono accadere. Il modello dei dati nella secondaria è qualunque cosa la replica asincrona abbia consegnato, applicata in ordine.
- Costo più basso. La compute della region secondaria può girare a una frazione della capacità della primaria, scalata in alto solo al failover.
- Consistenza più facile. C’è un solo writer; la replica è unidirezionale.
I punti deboli:
- Il failover è un’operazione vera. Richiede minuti o ore, non secondi. I TTL DNS si propagano lentamente. Le connessioni si svuotano. Il team deve esercitarsi sul failover, idealmente in game day regolari, altrimenti il runbook non funzionerà quando servirà.
- Il recovery time objective (RTO) è limitato dal tempo di failover. Se il team non si è esercitato e non ha investito in automazione, l’RTO è “il tempo che ci mette l’on-call a tirare fuori il runbook ed eseguirlo”. RTO realistici di active-passive nel 2026 vanno da minuti per team ben preparati a ore per team che scoprono il runbook per la prima volta in mezzo a un incidente.
- La region secondaria è capacità sprecata la maggior parte del tempo. La maggior parte dei team la mette in uso come read replica, il che aiuta sui costi ma aggiunge complessità operativa.
- Il recovery point objective (RPO) è limitato dal lag di replica. La replica asincrona significa che alcune scritture recenti vengono perse al failover. Per certi workload questo è un deal-breaker.
Active-active
Tutte le region servono traffico simultaneamente. La richiesta di un utente arriva alla region più vicina, la richiesta viene processata lì, e i dati vengono replicati alle altre region in background. Non c’è failover perché non c’è una primaria singola; se una region va giù, il traffico si sposta sulle altre.
I punti di forza:
- Niente failover. Se una region va giù, le altre continuano. L’RTO è il tempo che ci mette il DNS o il load balancer a rilevare l’outage e smettere di routare verso la region fallita (secondi o minuti).
- Latenza. Ogni utente è servito dalla region più vicina.
- La capacità è interamente utilizzata. Ogni region sta facendo lavoro vero tutto il tempo.
I punti deboli:
- Conflitti. Due region possono accettare scritture in conflitto sullo stesso record. L’utente aggiorna la sua email a Francoforte; un admin aggiorna l’email dello stesso utente in Virginia. Entrambe le scritture hanno successo localmente. La replica consegna ognuna all’altro lato, e il sistema deve riconciliare.
- La replica è più difficile. La replica bidirezionale ha più modalità di fallimento di quella unidirezionale.
- Requisiti applicativi più stringenti. L’applicazione deve essere progettata per eventual consistency, operazioni idempotenti, e risoluzione dei conflitti. Adattare un’applicazione esistente è costoso.
- Costo più alto. Tutte le region girano a scala di produzione tutto il tempo.
Il problema della risoluzione dei conflitti è la parte difficile dell’active-active. Le strategie nel 2026:
Last-write-wins. Ogni scrittura ha un timestamp; la più recente vince. Semplice, ma perde dati. Due scritture concorrenti valide diventano una, e la perdente sparisce.
Application-level merge. Quando il sistema rileva un conflitto, lo fa emergere all’applicazione o all’utente. “Due versioni di questo documento; quale vuoi?” Funziona per i documenti, non funziona per i contatori.
CRDT (Conflict-free Replicated Data Types). Strutture dati progettate in modo che due qualsiasi repliche possano essere fuse senza coordinamento, per costruzione. Un contatore CRDT si fonde sommando gli incrementi da ciascuna replica. Un set CRDT si fonde per unione. Il costo è che le strutture dati sono più complesse dei loro equivalenti non-CRDT, e non ogni dominio si presta a una forma CRDT.
Sharding per region. Il workaround più semplice: la home region di ogni utente è fissa, e le scritture per quell’utente vanno sempre alla home region. I conflitti non possono accadere perché c’è un solo writer per record. Il costo è che alcuni utenti ottengono latenza più alta quando viaggiano.
La scelta dipende dalla forma dei dati. Contatori: CRDT o sharded. Documenti: application-level merge o last-write-wins. Profili utente: sharded per region. La maggior parte dei sistemi active-active in produzione usa un mix.
Follow-the-sun
Una variante dell’active-active per servizi globali con forti pattern giornalieri. Il traffico si instrada alla region i cui utenti sono svegli. Il traffico APAC ha il picco durante gli orari business APAC; il traffico EMEA ha il picco durante gli orari EMEA; il traffico delle Americhe ha il picco durante gli orari US. Il sistema può spostare il workload tra le region per seguire la domanda.
Il caso d’uso più citato è operativo: lo staff di support e le rotation di on-call seguono il sole, con il team di ogni region che gestisce gli incidenti durante i suoi orari business locali. È più una questione di ops che di architettura, ma si manifesta nell’architettura quando il team costruisce tooling per tenere la region dell’on-call corrente come quella attiva per i workflow sensibili.
Il caso d’uso architetturale è l’ottimizzazione dei costi. La compute che è ferma durante la notte locale può essere scalata in basso o usata per job batch. Alcuni team fanno girare i loro workload analitici in qualunque region sia attualmente in bassa domanda di servire traffico.
Follow-the-sun è raramente la forma primaria. È un raffinamento sopra l’active-active per team che hanno pattern specifici da sfruttare.
I problemi difficili
I motivi per cui il multi-region costa più di quanto sembri:
Replica dei dati
La replica cross-region è ad alta latenza. Il round-trip cross-Atlantico più veloce è circa 70ms; quello cross-Pacifico è circa 130ms; quelli lunghi superano i 200ms. La replica sincrona attraverso le region uccide la latenza di scrittura: ogni scrittura deve aspettare almeno un round-trip cross-region. La replica asincrona è la scelta pragmatica per la maggior parte dei workload, ma significa che la region secondaria è sempre indietro, e il failover perde le scritture più recenti.
L’inquadramento PACELC dalla lezione 11 è esattamente il trade-off qui: in assenza di partition, il sistema sceglie tra latenza (asincrono, bassa latenza di scrittura, consistenza più debole) e consistenza (sincrono, latenza di scrittura più alta, consistenza più forte). Il multi-region costringe il team a fare questa scelta per ogni dataset.
Il toolset del 2026 è convergente su pochi pattern. Aurora Global Database, Spanner, Cosmos DB multi-region, e YugabyteDB offrono tutti punti diversi sulla curva latenza-consistenza. I database cloud-managed nascondono la maggior parte della complessità operativa ma non quella concettuale. Il team deve comunque sapere quale dataset è replicato in quale modo e quale RPO porta ognuno.
Costo della rete cross-region
La rete tra region non è gratis, e i cloud provider l’hanno resa il tier di banda più costoso che vendono. Il trasferimento dati AWS inter-region nel 2026 è dell’ordine di 0.02-0.09 USD per GB a seconda delle region coinvolte; GCP e Azure sono in fasce simili. Un’applicazione multi-region che replica ogni scrittura a ogni region paga per la banda su ogni byte.
I numeri sono piccoli per byte e grandi per mese. Un workload che spinge qualche terabyte al giorno di replica cross-region brucia attraverso una linea di budget significativa. L’active-active è più costoso dell’active-passive, in parte per via della compute e dello storage duplicati e in parte per via della replica chatty.
Le mitigazioni: replicare solo ciò che ha bisogno di essere replicato (i dati cold possono restare in una sola region); comprimere aggressivamente; fare batch dove il modello di consistenza lo permette; scegliere coppie di region che hanno pricing di trasferimento più basso.
Steering del traffico a livello DNS
Il sistema che decide quale region colpisce un utente è un layer sopra le region stesse. Le scelte nel 2026:
GeoDNS. Le risposte DNS dipendono dalla geografia dell’IP sorgente. Gli utenti in Europa ottengono l’IP di Francoforte; gli utenti negli US ottengono l’IP della Virginia. Semplice, ma lento a rispondere alle outage perché i TTL DNS sono tipicamente nell’ordine di minuti.
Latency-based routing. AWS Route 53, Cloudflare, e Akamai misurano la latenza da ogni utente a ogni region e instradano a quella di latenza più bassa. Meglio di GeoDNS per gli utenti vicini ai confini delle region.
Anycast. I load balancer dei cloud provider (AWS Global Accelerator, il global load balancer di GCP, la rete di Cloudflare) annunciano lo stesso IP da molte region. Il routing BGP di internet consegna ogni utente a quella più vicina. Failover sub-secondo quando una region va giù, perché il routing riconverge in BGP, non in DNS.
Il default del 2026 per deployment multi-region seri è anycast. GeoDNS è il fallback legacy.
Quando non andare in multi-region
La lista onesta dei casi in cui il multi-region è la scelta sbagliata:
Prodotto piccolo senza requisiti di latenza o DR. Un deployment single-region è drammaticamente più semplice e più economico. La maggior parte dei prodotti non ha bisogno del multi-region finché non ha product-market fit, clienti veri, e un revenue model vero che lo richieda.
Prodotto single-country. Un prodotto che serve solo un paese può di solito essere servito da una o due region in quel paese senza alcuna replica cross-region.
Le regolamentazioni regionali non si applicano. Se il tuo prodotto non ha utenti in region con regole di data residency, il motivo della compliance non si pone.
Non hai superato la capacità di una sola region. Le cloud region sono grandi. La maggior parte dei team che si preoccupa della capacità è ben lontana dal limite reale.
Il team non riesce a operarlo. Il multi-region non è un flag di configurazione. È un aumento sostanziale della complessità operativa, che include failover esercitato, code path di risoluzione dei conflitti, monitoring cross-region, e alerting sul lag di replica. Un team che fatica con le operazioni single-region farà ancora più fatica con il multi-region.
La progressione che la maggior parte dei prodotti segue: parti single-region. Resta single-region il più a lungo possibile. Aggiungi una secondaria passiva quando DR o compliance lo forzano. Aggiungi active-active solo quando latenza o capacità lo forzano. Ogni passo è un impegno architetturale vero su cui il team deve investire per anni.
I cross-reference chiudono l’apertura del modulo. Il teorema CAP dalla lezione 10 e PACELC dalla lezione 11 danno il vocabolario formale per i trade-off di consistenza che il multi-region forza. La lezione sul lag di replica (26) copre la realtà operativa della replica asincrona che questa lezione assume. L’inquadramento sui microservizi della lezione 73 si applica dentro ogni region; l’inquadramento event-driven della lezione 74 si applica attraverso le region quando i workload tollerano l’eventual consistency.
Il prossimo modulo si volge alle preoccupazioni che si appoggiano sopra l’architettura: sicurezza, costo, sostenibilità, e l’integrazione dell’AI nella piattaforma. Ognuna di quelle è un layer trasversale sopra qualunque forma l’architettura abbia preso. Le domande sulla forma, dopo questa lezione, sono assestate abbastanza da smettere di farsele.
Riferimenti
- AWS Multi-Region Application Architecture documentation,
https://docs.aws.amazon.com/whitepapers/latest/aws-multi-region-fundamentals/, consultato 2026-05-01. - Azure Architecture Center, “Multi-region deployments”,
https://learn.microsoft.com/azure/architecture/reliability/regions-paired, consultato 2026-05-01. - Google Cloud, “Multi-region patterns and practices”,
https://cloud.google.com/architecture/disaster-recovery, consultato 2026-05-01. - Marc Shapiro et al., “Conflict-free Replicated Data Types”, INRIA Technical Report, 2011. Il paper fondativo sui CRDT.
- AWS Aurora Global Database documentation,
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html, consultato 2026-05-01. - Google Cloud Spanner documentation,
https://cloud.google.com/spanner/docs/instances, consultato 2026-05-01. - Cloudflare, “How Anycast works”,
https://www.cloudflare.com/learning/cdn/glossary/anycast-network/, consultato 2026-05-01.