Reference Architecture: multi-region / global
When users are geographically distributed or resilience to a regional disaster is required, data spreads across multiple regions. This tree walks step by step through read locality (a read replica in each region), write topology (single-leader vs multi-leader vs quorum), data residency/compliance (GDPR), conflict resolution, and the trade-offs between RPO/RTO and latency. The basic truth: because of the laws of physics, low latency, strong consistency and multi-region writes cannot all be fully achieved at the same time; a deliberate trade-off is mandatory.
Why are you going multi-region: read locality, writes/resilience or compliance?
A multi-region architecture is costly and complex; clarify the motivation. Do you want low read latency for distant users, cross-region writes/disaster resilience, or is the real requirement that data stays in a specific country (legal residency)?
- Fast reads for distant users; writes can stay in one region
- Cross-region writes / resilience to losing a region are required
- Data must legally stay in a specific country/region
What should the write topology be: single-leader, multi-leader or quorum?
For cross-region writes, the key decision is the leadership model. Do all writes go to a single region (simple, consistent, but remote writes are slow), can every region write (low write latency but conflicts), or is a write accepted with the acknowledgment of a majority of regions (quorum: consistent but with added latency)?
- One region writes, the others read (simple and consistent)
- Every region can write locally (low write latency)
- Write with majority acknowledgment; consistency comes first
Recommendation: a read replica per region (read locality)
Writes stay in a single primary region while you place in each user region a read replica fed from it. Users read from the nearest replica and read latency drops; since writes still go to a single center, the consistency model stays simple.
Recommendation: single-leader writes
All writes go to a single leader region; the other regions are read replicas fed asynchronously from that leader. It is the simplest and most strongly consistent model; there are no conflicts because there is a single write point. The price is high write latency from remote regions.
Recommendation: multi-leader writes + conflict resolution
Because every region can write locally, write latency is low, and even if one region is cut off, the others keep writing. The price is heavy: two regions can update the same record differently, and you must design conflict resolution.
Recommendation: quorum-based writes (majority acknowledgment)
A write is accepted when a majority (quorum) of regions/replicas acknowledges it; when reads also go to a majority, the latest value is guaranteed. It is resilient to region loss and strongly consistent; the price is the latency of every write reaching a majority.
Recommendation: data residency / compliance (GDPR)
Some data (personal, health, financial) must legally remain within the borders of a specific country/region (e.g. GDPR). In this case you design the architecture not around 'copy everywhere' but so that data is pinned geographically.