advanced 2 min answer

A team must decide whether to run in one region or several. What evidence justifies multi-region, and what does it cost?

flyiomulti-regionlatencyavailabilitycomplexity
Show the full answer Hide the answer

The evidence that justifies it

  • A measured latency problem for a real user population, where the round trip is a product issue rather than a preference. "Users in another continent would be faster" is not evidence until someone has measured what that costs in conversion, abandonment or complaint.
  • A regulatory data residency requirement, which decides it regardless of performance.
  • An availability requirement that a single region cannot meet, which is a higher bar than it appears — a well-run multi-zone deployment in one region already survives most infrastructure failures.

What it costs

  • Data becomes the hard problem. Stateless tiers replicate trivially; state does not. Every strongly consistent invariant now needs a home, and cross-region coordination is expensive in latency and in failure modes.
  • Deployment and configuration become distributed operations, with the possibility of regions diverging.
  • Testing and debugging get harder, particularly for anything involving cross-region behaviour.
  • Cost rises more than proportionally, because each region needs its own headroom and the cross-region traffic is charged.

The design that makes it tractable

Entity homing: partition by customer or account and give each entity a home region that owns its writes. Reads are served locally from replicas everywhere; writes go to the home.

A regional outage then stops writes for the entities homed there and leaves everything else working — which is a far better failure profile than a single global primary, and it avoids the concurrent-write conflict resolution that global writable replication requires.

The trap to name explicitly

Global write replication proposed to reduce write latency. It creates concurrent writes to the same entity from multiple regions, requiring conflict resolution — which for anything with an invariant means either losing writes or inventing merge semantics nobody can reason about.

The evidence required is that write latency is genuinely a product problem, not that it would be nice.

The staged approach

One region, then read replicas elsewhere, then entity homing, then multi-region writes if ever. Each stage is a smaller step with its own evidence requirement, and most organisations correctly stop at the second or third.