Geo-distribution & Multi-region

Multi-region is expensive. Know the specific reason you need it — latency, availability, or regulation — before you do.

How It Works

Multi-region deployment replicates your system across geographically distinct data centers (see Replication Topologies for the underlying replication models). Three real reasons to do it: (1) latency — users in different regions need local response times (mobile apps, real-time gaming); (2) availability — surviving an entire region failure (rare but catastrophic); (3) regulation — data residency requirements (EU user data must stay in EU). The cost is substantial: 2–3× infrastructure spend, cross-region replication complexity, eventual consistency across regions, regulatory compliance overhead per region. Rule: don't go multi-region unless you can articulate which of the three reasons drives the decision. In interviews, state your reason explicitly before drawing multi-region boxes — "we need multi-region because of X" — not as a default assumption.

Real-World Example

Dropbox serves files globally but runs its primary services out of two US regions. Their user file data replicates asynchronously across POPs, but the "source of truth" lives in the US. They accepted higher latency for EU and APAC users in exchange for radically simpler consistency — a single writer region. When they later added true multi-region for regulatory reasons (GDPR), it was an 18-month migration project. Going multi-region is never free; walking back from it is even harder.