Multi-region
Multi-region
Bronze
Running the app in several cloud regions puts it near users on other continents and lets it survive a whole region going down. Copying the servers is the easy part; the data decides the design. Each region can keep a copy that is updated asynchronously — fast local reads and writes, but stale reads and conflicting writes between regions. Or replication can be synchronous, so every write waits for the far region. Or each user's data can live in one home region. Failover also needs spare capacity, because the surviving regions must carry the lost region's users.
- Use when
- Many users on other continents, where a cross-ocean round trip is a large part of every request · The app must keep running through the loss of a whole region · Data that must stay in a given country or region
- Avoid when
- Users are in one area and availability zones already meet the availability target · Static files are the slow part — a CDN is enough · The team can't yet run and test failover — an untested second region gives false comfort
- Trade-offs
- Lower latency and region-level resilience, for duplicated resources, traffic between regions and the work of running several deployments · Asynchronous copies are fast but can be stale, strand writes not yet copied when a region fails, and conflict · Synchronous replication keeps regions in step, but every write waits for the farthest region · A home region per user keeps data local and lawful, but load follows where users live, and anything global crosses regions
- Requires
- Sharding, CDN (content delivery network), Failure modes & availability
3 objectives · 23 misconceptions
- predict Predict a user's response time when the request is served in a nearby region, and when a call in that request crosses back to a distant region.
- explain Explain how traffic moves to another region when one fails, why some requests fail before it does, and why the surviving regions need spare capacity.
- choose Choose how data lives across regions — asynchronous copies, synchronous replication, or a home region per user — from what the app can accept — stale reads and conflicts, slower writes, or data tied to one place.
- Not true: Running the app servers in a second region makes the app fast there, even if the database stays in the first region.
- Not true: When a region goes down, traffic moves to another one at once, without a single failed request.
- Not true: A copy in another region always shows the latest write.
- Not true: A region that normally serves half the users can take all of them the moment the other region fails.
- Not true: Synchronous replication between regions gives every region the latest data at no cost in write speed.
- Not true: Letting every region accept writes is safe, because two regions can't change the same item at the same time.
- Not true: A CDN already makes the whole app multi-region.
- Not true: Spreading servers across availability zones protects against a whole region going down.
- Not true: Response time depends only on the servers, not on how far away the user is.
- Not true: Moving the web servers away from the database adds a second ocean crossing on top of the user's.
- Not true: A database pushed past its limit keeps serving up to its limit on its own and only turns away the extra.
- Not true: Spare capacity costs nothing until it's used.
- Not true: A request to a far region costs only the one-way trip, not the way back.
- Not true: A region can't read or write an item while a change to it is being copied between regions.
- Not true: Synchronous replication makes reads slow, because each read has to check the far region.
- Not true: When two regions change the same item at once, one of the writes fails with an error the user can retry.
- Not true: Failover has to start new servers in the surviving region, so users wait for them to boot.
- Not true: Capacity that sits idle on a normal day is wasted money.
- Not true: Sizing a region to carry its partner makes its everyday requests slower.
- Not true: Availability zones in one region always fail together, so they protect against nothing.
- Not true: Copying data to every region still keeps each user's data in their own region.
- Not true: Another region is always worth adding, because more regions are always more reliable.
- Not true: A second region makes pages faster for every user, wherever they are.
Stories here
Neighborhood
→Multi-region→
unlocksnothing yet
contrast withCDN (content delivery network)