# Multi-region architecture > Multi-region architecture runs a service across separate geographic regions to reduce user latency, survive regional outages, or meet data residency requirements. The hard part is not deploying more servers: it is deciding where writes happen, how data moves, and what remains correct when regions cannot communicate. Source: https://sysround.com/concepts/multi-region-architecture Updated: 2026-11-05 ## How multi-region architecture works Start with the requirement that justifies multiple regions. A global audience may need nearby reads, while an availability target may require surviving the loss of an entire region. Multiple availability zones within one region protect against a different failure scope. Choose an operating model. In active-passive, one region serves production traffic and another waits to take over. In active-active, multiple regions serve traffic simultaneously. Specify the layer: active-active application servers can still use a single database writer, so active-active does not automatically mean local writes everywhere. Route requests through health-aware global load balancing or DNS. Keep application servers close to users, but route writes to the region that owns the relevant data. For example, accounts can have home regions, allowing both regions to accept traffic without letting both independently modify the same account. Choose replication and acknowledgment rules. Asynchronous cross-region replication keeps remote acknowledgment off the write path, but replicas can lag and acknowledged writes may be lost if their only durable region fails. Synchronous replication can protect acknowledged writes against the failures covered by its replica placement and quorum, at the cost of cross-region latency and potentially unavailable writes during partitions. Define behavior when regions cannot communicate. A single-writer design must prevent two regions from becoming authoritative for the same data, typically through quorum-backed ownership and fencing. A multi-writer design needs explicit conflict semantics; merging shopping-list additions is different from enforcing one remaining seat. Plan both failover and failback. Detect the outage, establish safe write authority, verify replica state, redirect traffic, and ensure surviving regions have capacity. State the recovery time objective, or RTO, and recovery point objective, or RPO; then test recovery and resynchronize a returning region before giving it ownership again. ## Worked example: Active-active serving with account-owned writes Suppose a streaming service runs in two regions and allows three simultaneous streams per account. Both regions serve playback requests, but each account has one home region that atomically allocates stream leases. Lease state replicates asynchronously to the other region. During a partition, letting both regions allocate from their local copies could admit six streams. The design therefore rejects new starts when the account's authoritative allocator is unreachable; existing playback continues only while its current authorization remains valid. After an outage, promotion requires fencing the old allocator and accounting for potentially missing leases, such as waiting for outstanding authorizations to expire before reusing slots. This sacrifices new-start availability to preserve the account-wide limit. ## Trade-offs - **Local latency versus global coordination.** Nearby application servers help only if the critical request path does not still wait on a distant database or cross-region quorum. - **Durability versus write availability.** Waiting for remote durable acknowledgments can reduce data loss, but writes may have to stop when the required regions cannot communicate. - **Multi-writer availability versus conflict complexity.** Independent regional writes require application-specific reconciliation and cannot preserve every global invariant without coordination or preallocated rights. - **Regional resilience versus spare capacity.** Surviving regions need enough reserved or quickly available capacity to absorb displaced traffic without causing a second outage. - **Geographic reach versus data residency.** Replication, backups, logs, and failover destinations must all respect where regulated data is allowed to reside. - **Availability gains versus operational cost.** Additional infrastructure, cross-region transfer, deployment coordination, and recovery testing make multi-region operation substantially more demanding. ## When to use it in a system design interview - The interviewer requires continued operation after a complete regional outage, with explicit recovery and data-loss targets. - Users are geographically distributed and a single region cannot meet the latency budget for important requests. - The system must keep particular tenants or data categories within approved geographic boundaries. - Regional partitions or cross-region reconnects directly affect correctness, such as account-wide admission limits or ordered price updates. ## How to bring it up in the interview - Ask for latency targets, allowed data loss, recovery time, and residency constraints before proposing active-active; distinguish those needs from ordinary multi-zone availability. - Draw one read path and one write path, naming the data owner, replica locations, acknowledgment condition, and behavior when a remote region is unreachable. - Separate active-active serving from multi-writer storage, and defend the simplest ownership model that meets the requirements. - Walk through a network partition rather than only a clean regional crash; expect questions about who can promote a writer, how the old writer is fenced, and what happens to acknowledged writes. - Explain capacity and recovery testing, including stale replicas, retries with shared idempotency state or authoritative deduplication, gradual traffic shifts, and safe failback. ## Common mistakes - Assuming active-active means every region can safely update every record independently. - Treating a DNS change as complete failover while ignoring cached answers, existing connections, database authority, and replica lag. - Claiming asynchronous replication guarantees zero data loss or immediate read-your-writes behavior after switching regions. - Promoting a second writer based only on a failed health check, without preventing the original writer from continuing to accept writes. - Sizing each region only for normal traffic or leaving critical authentication, configuration, or routing dependencies in one region. ## Interview questions where it comes up - [Design Netflix's concurrent screen limit](https://sysround.com/questions/design-netflix-screen-limit): Regional failures force an explicit choice between available local admissions and preserving an account-wide stream limit. - [Design a real-time stock price feed](https://sysround.com/questions/design-stock-price-feed): Cross-region reconnects require version-aware delivery so a lagging region does not move a client's displayed price backward. - [Design a distributed key-value store](https://sysround.com/questions/design-key-value-store): Replica placement, partition behavior, write authority, and convergence determine how the store behaves across regional failures. ## FAQ ### What is the difference between active-active and active-passive multi-region architecture? Active-active means multiple regions serve production traffic at the same time; active-passive keeps a standby region ready to take over. Neither term alone defines database consistency or data-loss guarantees. Always specify whether applications, reads, and writes are active in each region. ### Does multi-region active-active require a multi-writer database? No. Application servers can serve traffic in several regions while forwarding writes to a single leader or to a home region for each account or partition. This avoids concurrent ownership of the same data, but some requests pay cross-region latency and may become unavailable when their owner is unreachable. ### Can multi-region architecture provide zero data loss? It can protect acknowledged writes against specified regional failures if acknowledgment requires durable replication to a replica set that survives those failures. That guarantee depends on replica placement, quorum rules, and safe promotion, not merely having a second region. Asynchronous replication alone cannot guarantee zero loss of acknowledged writes during an unexpected regional failure. ## Related concepts - [Database replication](https://sysround.com/concepts/replication) - [Failover](https://sysround.com/concepts/failover) - [Disaster recovery, RPO and RTO](https://sysround.com/concepts/disaster-recovery) - [Split brain](https://sysround.com/concepts/split-brain) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.