Multi-Region | System Design Interview Handbook

🌍

Why Go Multi-Region

three drivers, three different designs

Multi-region is expensive and complex, so the first question is why — because each reason implies a different design.

Driver	What it demands
Latency to global users	Serve each user from a nearby region — active-active
Disaster recovery	A standby that survives losing a region — active-passive
Data residency law	Keep certain data in certain jurisdictions — regional partitioning

💡

Pin down the driver before designing. "Multi-region for low global latency" and "multi-region for DR" are different systems — one needs local writes everywhere, the other needs a warm standby. Ask which one, or state your assumption, before drawing regions (Design Process).

🛟

Active-Passive

a standby that waits for disaster

One region serves all traffic; a second stands by, kept current by replication. If the primary dies, you promote the standby. Simpler than active-active because only one region takes writes — no conflicts. The two numbers that define it are RTO and RPO.

  ┌────────────┐   async replication    ┌────────────┐
  │  PRIMARY    │ ─────────────────────▶ │  STANDBY    │
  │  all traffic│                        │  idle, warm │
  └────────────┘   ◀── failover ──▶      └────────────┘

  RTO — Recovery Time Objective: how long until you're back up (failover speed)
  RPO — Recovery Point Objective: how much data you can lose (replication lag)
        the async lag IS your data-loss window

⚠️

A failover path that's never tested doesn't work — DNS is stale, the standby's capacity was quietly scaled down, a config drifted. Untested DR is theater. And the replication lag is a real data-loss window: with async replication, writes acked by the primary but not yet shipped are gone when you promote (Replication). RPO isn't zero unless you paid for synchronous replication and its latency.

⚡

Active-Active

every region serves — and the write problem

Every region serves live traffic, each user hitting the nearest one. Reads are easy — a local replica in each region. Writes are the whole difficulty, and there are three ways to handle them.

Write approach	How	Cost
Single global write region	All writes route to one region; others read local	Distant users pay latency on every write
Region-local writes	Each region takes writes, replicates to others	Write conflicts — needs resolution (multi-leader)
Partition by home region	Each user's data lives in their home region	Cross-region access is slow / complex

Partitioning users by home region is often the cleanest: a user's writes always go to their own region, so there's no conflict, and only the rare cross-region interaction pays the price. It sidesteps the conflict problem instead of solving it — which is usually the better trade (Tradeoffs).

⚖️

Data Residency

the law decides where bytes live

Regulations like GDPR can require that data about EU users physically stays in the EU. That forces regional partitioning: each user's personal data is pinned to their jurisdiction, with only non-personal or aggregated metadata replicated globally.

⚠️

Residency quietly breaks global queries. "Show me all users sorted by signup date" can no longer hit one table — the data is scattered across jurisdictions that legally can't be merged in one place. You answer such queries by querying each region and merging, or by keeping a separate, legally-clean global index of non-personal fields. Naming that consequence shows you understand residency isn't just a storage location, it reshapes every cross-region read.

🧭

Routing Users to Regions

getting them to the right one, and off a dead one

Two mechanisms send users to a region. GeoDNS resolves the domain to the nearest region's address; anycast advertises one IP from many locations and lets the network route to the closest, reacting faster than DNS with no TTL wait (Discovery).

ℹ️

When a region dies, in-flight sessions there are simply gone — routing sends new requests elsewhere, but anything mid-flight is lost unless the client retries. This is why session state belongs in a store, not on a regional server, and why clients need retry-with-backoff: the region a user was pinned to can vanish between two requests (Resilience).

🐢

The Cost: Cross-Region Latency

regions are islands

The physics is unforgiving: a round trip between regions is ~100ms or more, bounded by the speed of light. Any design where serving a request means a synchronous call to another region is poisoned — that 100ms lands on every request, defeating the reason you went multi-region.

⚠️

The design rule: regions are islands that sync asynchronously. A request must be servable entirely within its own region — local reads, local writes where possible — with cross-region replication happening in the background, off the request path. The moment a user request blocks on another region, you've built something slower than a single region would have been. If you find a synchronous cross-region hop in your design, that's the thing to fix.

📋

Quick Reference

active-passive vs active-active

	Active-passive	Active-active
Traffic	Primary only; standby idle	All regions serve
Writes	One region — no conflicts	The hard part — needs a strategy
RTO / RPO	Failover time / replication lag	Near-zero if partitioned right
Cost	Lower — standby mostly idle	Higher — full capacity everywhere
Complexity	Moderate; test the failover	High; conflict + residency
Best for	Disaster recovery	Low global latency

Region checklist
Pin down the driver: latency, DR, or residency?
Where do writes go, and how are conflicts handled?
No synchronous cross-region calls on the request path
Session state in a store, not on a regional server
Is the failover actually tested?

ℹ️

The one-liners to keep ready. Name the driver first — latency, DR, or residency — because each implies a different design. Active-passive for DR (watch RPO and test the failover); active-active for latency (the write problem is everything, partition by home region to dodge conflicts). Residency breaks global queries. And the rule that governs all of it: regions are islands that sync asynchronously — never a synchronous cross-region hop on the request path.