Part 9 · 1 chapters · ~10 min
Multi-region and Traffic Management
When to run in more than one region and what it costs: steering with DNS, anycast and global load balancers, active-passive and active-active designs and the write problem, data residency with home regions, and failover as a rehearsed procedure that the frontend must also survive.
17
Where requests go, and what each region may do
| pattern | writes | failover | cost | fits |
|---|---|---|---|---|
| single region, multi-zone | one writer | automatic within region | lowest | most products; start here |
| active-passive | one writer, async replica | minutes; some data at risk | standby capacity | regional disaster recovery |
| active-active, home region per user | each user writes in their home | re-home users when a region fails | high | residency plus latency, per-country platforms |
| active-active, global consensus | any region, consensus round trips | automatic | highest; slower writes | ledgers needing global strong consistency |
the frontend's part
The client should know its home region (the Platform course, part 1), send requests there directly or through a global load balancer, and handle a short burst of errors and a possible re-authentication during failover without losing a form in progress. Persist drafts locally, retry idempotently, and say what is happening.
MULTI-REGION AND TRAFFIC MANAGEMENT
steering users to the right place, surviving a region, and keeping data where the law says it lives
swipe the figure sideways, or tap expand for full screen
1/6
why
Why go multi-region, honestly: latency (a user in Lagos reaching a server in Ireland pays a long round trip on every request), availability (surviving the loss of a whole region, which is rare but happens), and residency (some data must stay in a country or region). If none of these is a requirement, one region with several zones is usually enough.