Lecția 73 a ales forma serviciilor. Lecția 74 a ales forma conversațiilor dintre ele. Lecția asta alege forma geografiei. Odată ce arhitectura e decisă și workflow-urile sunt așezate, următoarea întrebare care cade pe echipă e „ce se întâmplă când una dintre regiunile noastre cade?” sau „ce se întâmplă când utilizatorii noștri europeni se plâng că aplicația e lentă?”. Ambele întrebări arată spre același răspuns: multi-region. Și ambele vin cu o etichetă de preț la care echipa trebuie să se uite cinstit înainte să semneze.
Asta e lecția care închide deschiderea Modulului 10. După ea, restul modulului se întoarce spre preocupările transversale (securitate, cost, sustenabilitate, integrare cu AI) care stau peste orice formă a apucat echipa să stabilească. Geografia e ultima decizie arhitecturală mare înainte ca acele preocupări să preia.
De ce echipele aleg multi-region
Cele patru motive, cam în ordinea în care împing majoritatea echipelor peste limită:
Latență. Utilizatorii de pe partea cealaltă a lumii experimentează latența vitezei luminii, plus viteza efectivă a rețelei care e mai proastă. Un request din Sydney spre un data center US-East e cam 200ms one-way înainte ca aplicația să facă ceva. Pentru o pagină singulară poate fi tolerabil; pentru o aplicație cu multă comunicație sau ceva real-time nu e. Servirea utilizatorilor din Sydney dintr-o regiune Sydney coboară round-trip-ul înapoi la milisecunde dintr-o cifră.
Disaster recovery. O cădere la nivel de regiune întreagă la oricare dintre cloud providerii majori se întâmplă. AWS US-East-1 a avut câteva căderi de mai multe ore în ultimul deceniu. Azure a avut incidente DNS și de storage la nivel de regiune. GCP a avut căderi de control plane. Când întreaga regiune în care trăiește produsul tău e jos, „va reveni când AWS revine” nu e un răspuns satisfăcător de dat unui client care plătește pentru un SLA. Multi-region cu capacitatea de a face failover e apărarea.
Conformitate. GDPR (UE), CCPA (California), LGPD (Brazilia), Personal Information Protection Law (China) și o listă în creștere de reglementări regionale specifică unde pot fi stocate și procesate datele personale. Același produs care livrează global trebuie să țină datele utilizatorilor europeni în data centre europene, uneori datele utilizatorilor chinezi în data centre chinezești, iar uneori datele utilizatorilor ruși în data centre rusești. Conformitatea e cel mai absolut dintre motive: nu e despre performanță sau disponibilitate, e despre dacă ai voie să operezi.
Capacitate. O minoritate mică de produse depășesc capacitatea unei singure regiuni. Regiunile cloud sunt mari; cazul ăsta e rar pentru majoritatea echipelor. Când se întâmplă, a doua regiune e adăugată pentru că prima nu mai poate ține sarcina.
Primele trei conduc majoritatea adopției multi-region. Al patrulea e un trigger real dar neobișnuit.
Cele trei forme de deployment
Odată ce echipa a decis să meargă multi-region, trei forme sunt opțiunile din meniu.
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
Regiunea primară servește tot traficul. Regiunea secundară rulează același stack, ține o replică a datelor și e altfel inactivă. Când regiunea primară cade, echipa (sau un proces automat) bascule DNS-ul, iar secundara devine primara. Asta e forma tradițională de disaster recovery, folosită de mult înainte ca „multi-region” să fie expresia la modă pentru ea.
Punctele forte:
- Mai simplu operațional. La un moment dat servește o singură regiune. Conflictele între regiuni nu pot apărea. Modelul de date din secundară e ce a livrat replicarea async, aplicat în ordine.
- Cost mai mic. Compute-ul regiunii secundare poate rula la o fracțiune din capacitatea primarei, ridicat doar la failover.
- Consistență mai ușoară. E un singur scriitor; replicarea e unidirecțională.
Punctele slabe:
- Failover-ul e o operațiune reală. Durează minute până la ore, nu secunde. TTL-urile DNS se propagă lent. Conexiunile se scurg. Echipa trebuie să exerseze failover-ul, ideal în game days regulate, altfel runbook-ul nu va funcționa când va fi nevoie.
- Recovery time objective (RTO) e mărginit de timpul de failover. Dacă echipa n-a exersat și n-a investit în automatizare, RTO-ul e „cât îi ia on-call-ului să scoată runbook-ul și să-l execute”. RTO-uri active-passive realiste în 2026 variază de la minute pentru echipe bine pregătite la ore pentru echipe care descoperă runbook-ul prima oară în mijlocul incidentului.
- Regiunea secundară e capacitate irosită majoritatea timpului. Majoritatea echipelor o pun la treabă ca read replica, ceea ce ajută cu costul dar adaugă complexitate operațională.
- Recovery point objective (RPO) e mărginit de lag-ul de replicare. Replicarea async înseamnă că niște scrieri recente sunt pierdute la failover. Pentru unele workload-uri ăsta e un deal-breaker.
Active-active
Toate regiunile servesc trafic simultan. Un request al utilizatorului lovește regiunea cea mai apropiată, request-ul e procesat acolo, iar datele sunt replicate spre celelalte regiuni în fundal. Nu există failover pentru că nu există un primar unic; dacă o regiune cade, traficul se mută spre celelalte.
Punctele forte:
- Fără failover. Dacă o regiune cade, celelalte continuă. RTO-ul e timpul în care DNS-ul sau load balancer-ul detectează căderea și nu mai rutează spre regiunea defectă (secunde până la minute).
- Latență. Fiecare utilizator e servit din regiunea cea mai apropiată.
- Capacitatea e folosită complet. Fiecare regiune face muncă reală tot timpul.
Punctele slabe:
- Conflicte. Două regiuni pot accepta scrieri conflictuale pe același record. Utilizatorul își actualizează emailul în Frankfurt; un admin actualizează emailul aceluiași utilizator în Virginia. Ambele scrieri reușesc local. Replicarea livrează fiecare spre cealaltă parte, iar sistemul trebuie să reconcilieze.
- Replicarea e mai grea. Replicarea bidirecțională are mai multe moduri de eșec decât cea unidirecțională.
- Cerințe mai puternice asupra aplicației. Aplicația trebuie proiectată pentru eventual consistency, operații idempotente și rezolvare de conflicte. Retrofit-ul pe o aplicație existentă e scump.
- Cost mai mare. Toate regiunile rulează la scară de producție tot timpul.
Problema rezolvării conflictelor e partea grea a active-active. Strategiile în 2026:
Last-write-wins. Fiecare scriere are un timestamp; cea mai târzie câștigă. Simplu, dar pierde date. Două scrieri concurente valide devin una, iar perdantul e dispărut.
Application-level merge. Când sistemul detectează un conflict, îl ridică spre aplicație sau spre utilizator. „Două versiuni ale documentului ăsta; pe care o vrei?” Funcționează pentru documente, nu funcționează pentru contoare.
CRDTs (Conflict-free Replicated Data Types). Structuri de date proiectate astfel încât oricare două replici să poată fi merge-uite fără coordonare, prin construcție. Un contor CRDT face merge prin sumarea incrementelor de la fiecare replică. Un set CRDT face merge prin reuniune. Costul e că structurile de date sunt mai complexe decât echivalentele lor non-CRDT, iar nu orice domeniu se potrivește unei forme CRDT.
Sharding după regiune. Soluția cea mai simplă: regiunea de domiciliu a fiecărui utilizator e fixă, iar scrierile pentru acel utilizator merg întotdeauna în regiunea de domiciliu. Conflictele nu pot apărea pentru că există un singur scriitor per record. Costul e că unii utilizatori primesc latență mai mare când călătoresc.
Alegerea depinde de forma datelor. Contoare: CRDT sau sharded. Documente: application-level merge sau last-write-wins. Profile de utilizator: sharded după regiune. Majoritatea sistemelor active-active de producție folosesc un amestec.
Follow-the-sun
O variantă de active-active pentru servicii globale cu pattern-uri zilnice puternice. Traficul e rutat spre regiunea ai cărei utilizatori sunt treji. Traficul APAC are vârf în orele de business APAC; traficul EMEA are vârf în orele EMEA; traficul Americas are vârf în orele US. Sistemul poate muta workload-ul între regiuni ca să urmeze cererea.
Cazul de utilizare cel mai citat e operațional: personalul de support și rotațiile de on-call urmează soarele, fiecare echipă regională gestionând incidentele în orele de business locale. Asta e mai mult despre ops decât arhitectură, dar apare în arhitectură când echipa construiește tooling care să țină regiunea on-call ca regiune activă pentru workflow-urile sensibile.
Cazul de utilizare arhitectural e optimizarea costului. Compute-ul care e inactiv în noaptea locală poate fi scalat în jos sau folosit pentru job-uri batch. Unele echipe își rulează workload-urile de analytics în orice regiune e curent în cerere mică pentru servirea traficului.
Follow-the-sun e rar forma primară. E o rafinare peste active-active pentru echipele care au pattern-uri specifice de exploatat.
Problemele grele
Motivele pentru care multi-region costă mai mult decât pare:
Replicarea datelor
Replicarea cross-region are latență mare. Cel mai rapid round-trip cross-Atlantic e cam 70ms; cross-Pacific e cam 130ms; cele lungi sunt peste 200ms. Replicarea sincronă cross-region omoară latența scrierii: fiecare scriere trebuie să aștepte cel puțin un round-trip cross-region. Replicarea async e alegerea pragmatică pentru majoritatea workload-urilor, dar înseamnă că regiunea secundară e mereu în urmă, iar failover-ul pierde scrierile cele mai recente.
Cadrul PACELC din lecția 11 e exact compromisul de aici: în absența partiționărilor, sistemul alege între latență (async, latență mică de scriere, consistență mai slabă) și consistență (sync, latență mai mare de scriere, consistență mai puternică). Multi-region forțează echipa să facă această alegere pentru fiecare set de date.
Setul de unelte din 2026 a convergat pe câteva pattern-uri. Aurora Global Database, Spanner, Cosmos DB multi-region și YugabyteDB oferă toate puncte diferite pe curba latență-consistență. Bazele de date gestionate de cloud ascund majoritatea complexității operaționale, dar nu și pe cea conceptuală. Echipa tot trebuie să știe care set de date e replicat în care fel și ce RPO duce fiecare.
Costul rețelei cross-region
Rețeaua dintre regiuni nu e gratuită, iar cloud providerii au făcut din ea cel mai scump nivel de bandă pe care îl vând. Transferul AWS inter-regiune în 2026 e de ordinul a 0.02 până la 0.09 USD per GB în funcție de regiunile implicate; GCP și Azure sunt în intervale similare. O aplicație multi-region care replică fiecare scriere în fiecare regiune plătește banda pentru fiecare octet.
Numerele sunt mici per octet și mari per lună. Un workload care împinge câțiva terabytes pe zi de replicare cross-region arde printr-o linie de buget semnificativă. Active-active e mai scump decât active-passive, parțial din cauza compute-ului și storage-ului duplicate și parțial din cauza replicării vorbărețe.
Mitigațiile: replică doar ce trebuie replicat (datele reci pot rămâne într-o singură regiune); comprimă agresiv; fă batching unde permite modelul de consistență; alege perechi de regiuni cu prețuri de transfer mai mici.
Direcționarea traficului la nivel de DNS
Sistemul care decide ce regiune lovește un utilizator e un strat deasupra regiunilor în sine. Alegerile în 2026:
GeoDNS. Răspunsurile DNS depind de geografia IP-ului sursă. Utilizatorii din Europa primesc IP-ul Frankfurt; utilizatorii din US primesc IP-ul Virginia. Simplu, dar lent să răspundă la căderi pentru că TTL-urile DNS sunt de obicei minute.
Latency-based routing. AWS Route 53, Cloudflare și Akamai măsoară latența de la fiecare utilizator la fiecare regiune și rutează spre cea cu latența minimă. Mai bun decât GeoDNS pentru utilizatori aproape de granițele regiunilor.
Anycast. Load balancer-ele de cloud (AWS Global Accelerator, load balancer-ul global GCP, rețeaua Cloudflare) anunță același IP din mai multe regiuni. Rutarea BGP a internetului livrează fiecare utilizator la cea mai apropiată. Failover sub-secundă când o regiune cade, pentru că rutarea reconverge în BGP, nu în DNS.
Implicitul din 2026 pentru deployment-uri multi-region serioase e anycast. GeoDNS e fallback-ul moștenit.
Când să nu mergi multi-region
Lista cinstită de cazuri în care multi-region e alegerea greșită:
Produs mic fără cerințe de latență sau DR. Un deployment într-o singură regiune e dramatic mai simplu și mai ieftin. Majoritatea produselor n-au nevoie de multi-region până nu au product-market fit, clienți reali și un model real de venituri care îl cere.
Produs cu o singură țară. Un produs care servește o singură țară poate fi de obicei servit din una sau două regiuni din acea țară fără replicare cross-region.
Reglementările regionale nu se aplică. Dacă produsul tău nu are utilizatori în regiuni cu reguli de rezidență a datelor, motivul de conformitate e irelevant.
N-ai depășit capacitatea unei singure regiuni. Regiunile cloud sunt mari. Majoritatea echipelor care își fac griji pentru capacitate sunt nicăieri aproape de limita reală.
Echipa nu o poate opera. Multi-region nu e un flag de configurare. E o creștere substanțială de complexitate operațională, incluzând failover exersat, căi de cod pentru rezolvarea conflictelor, monitorizare cross-region și alerting pentru lag-ul de replicare. O echipă care se chinuie cu operațiile pe o singură regiune se va chinui mai rău cu multi-region.
Progresia pe care o urmează majoritatea produselor: începe single-region. Rămâi single-region cât mai mult timp posibil. Adaugi o secundară pasivă când DR sau conformitatea o forțează. Adaugi active-active doar când latența sau capacitatea o forțează. Fiecare pas e un angajament arhitectural real în care echipa trebuie să investească ani de zile.
Trimiterile încrucișate închid deschiderea modulului. Teorema CAP din lecția 10 și PACELC din lecția 11 dau vocabularul formal pentru compromisurile de consistență pe care le forțează multi-region. Lecția despre replication lag (26) acoperă realitatea operațională a replicării async pe care lecția asta o presupune. Cadrul de microservices din lecția 73 se aplică în interiorul fiecărei regiuni; cadrul event-driven din lecția 74 se aplică între regiuni atunci când workload-urile tolerează eventual consistency.
Modulul următor se întoarce spre preocupările care stau deasupra arhitecturii: securitate, cost, sustenabilitate și integrarea AI-ului în platformă. Fiecare dintre acestea e un strat transversal peste orice formă a apucat arhitectura să stabilească. Întrebările despre formă, după lecția asta, sunt așezate suficient cât să nu mai fie întrebate.
Citations
- AWS Multi-Region Application Architecture documentation,
https://docs.aws.amazon.com/whitepapers/latest/aws-multi-region-fundamentals/, retrieved 2026-05-01. - Azure Architecture Center, “Multi-region deployments”,
https://learn.microsoft.com/azure/architecture/reliability/regions-paired, retrieved 2026-05-01. - Google Cloud, “Multi-region patterns and practices”,
https://cloud.google.com/architecture/disaster-recovery, retrieved 2026-05-01. - Marc Shapiro et al., “Conflict-free Replicated Data Types”, INRIA Technical Report, 2011. The foundational CRDT paper.
- AWS Aurora Global Database documentation,
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html, retrieved 2026-05-01. - Google Cloud Spanner documentation,
https://cloud.google.com/spanner/docs/instances, retrieved 2026-05-01. - Cloudflare, “How Anycast works”,
https://www.cloudflare.com/learning/cdn/glossary/anycast-network/, retrieved 2026-05-01.