Need a second region?
Bad: Active-active everywhere
About 2× the cost, plus replication, failover and routing: new things that fail.
Good: Ask why first
Far users, an RTO one region can’t meet, or residency. Otherwise, multi-AZ first.
One question: which region may write this record right now?
One region, one primary with local reads, the user’s home region, or any region. Only “any” has conflicts.
2,400
acknowledged writes the new primary never saw
Async replication ships changes after the commit. At 3,000 writes/s and 0.8 s of lag, a dying region strands its tail: the lag is your RPO.
One family cart, edited in two regions 0.3 s apart
Neither saw the other’s write. Last writer wins converges as reliably as a merge, on the wrong answer. The milk vanishes, and nobody is told.
Two regions create one username at once, “only if it doesn’t exist”.
The catch
Each check reads only its local copy. Both pass; last writer wins quietly keeps one account. Uniqueness needs one owner or consensus.
One food-delivery app, a different answer per data type
Choose per data type, not per system. Last writer wins suits rider locations, where only the newest point matters, but never the ledger.
66.7%
how busy each of three regions may run
Lose one and the two survivors split its traffic, so the fleet is 1.5× the load. With N regions, each runs at most (N − 1)/N.
Remember
Go multi-region only for far users, a bounded RTO or residency. Home each user in one region and alarm on replication lag.