Engineering Atlas › System Design Interviews

Designing for several regions

14 min read · last reviewed 2026-10-17

Open in the interactive app: practice, quiz, mock interview →

In one minute

How it works

Stateless tiers are easy

Web and API servers can run in every region behind global DNS routing or anycast, sending each user to the nearest healthy region. Static content goes to a CDN. The hard part is always the data.

Active-passive

One primary region takes writes; the database replicates asynchronously to a standby region that may serve reads. On regional failure, operators (or automation) promote the standby and shift traffic. This keeps a single-writer model, so no conflicts, but writes from far away pay the round trip to the primary, failover loses whatever had not replicated (the recovery point objective, RPO), and the switch takes minutes (the recovery time objective, RTO). The RPO is a per-transaction dial in some databases: Postgres's synchronous_commit ranges from local (no wait for any standby) through on (standby has flushed the commit) to remote_apply (standby has replayed it and can serve it) (Postgres docs), so a payment can wait for the remote region while a page view does not. It is the most common starting point.

Active-active with home regions

Each user, tenant or account is assigned a home region, and all writes for that entity go there. Every region serves reads for everyone (possibly stale for remote entities) and writes for its own residents. This gives local latency to most users and no write conflicts, because each record has one owner. The costs: a routing layer that knows each entity's home, cross-region operations (a user in Europe messaging a user in Asia) that must touch two regions, and a migration process when users move.

Active-active multi-writer

Any region accepts writes for any record and replicates to the others asynchronously. Two regions can update the same record concurrently; the system resolves conflicts with a rule. Last-writer-wins by timestamp is simple but silently drops one update. The alternative is to keep both versions and let the application merge them: Amazon's original Dynamo tracked versions with vector clocks and merged divergent shopping carts, so an "add to cart" was never lost, though a deleted item could reappear (DeCandia et al., SOSP 2007). CRDTs (counters, sets, registers with merge functions) converge without loss for suitable data types. DynamoDB global tables and Cassandra multi-datacenter clusters work this way by default. Watch the edges of "by default": in DynamoDB's default eventual mode a transaction is atomic only in the region that ran it, so another region can briefly see half of it (AWS docs).

Globally consistent databases

Spanner, CockroachDB and similar systems run consensus groups whose replicas span regions, so a write commits once a majority acknowledges it. You get serializable transactions everywhere at the cost of cross-region latency on writes (and sometimes reads). Placement controls (keeping a row's leader near its users) recover much of the latency. Managed key-value stores now offer the same trade as a switch: DynamoDB's multi-Region strong consistency mode, chosen when a global table is created, writes synchronously to at least one other region before acknowledging, gives an RPO of zero, and must span exactly three regions (three replicas, or two plus a witness). It gives up transactions, TTL and local secondary indexes, and it rejects a write that races one in another region with ReplicatedWriteConflictException instead of silently picking a winner (AWS docs).

How it shows up in interviews

Triggers: "users are worldwide," "must survive a region outage," "EU data must stay in the EU," designs like WhatsApp, Uber, Netflix, a global payment system or a multiplayer game. A strong answer states the goal, picks a pattern per data type (not one for everything), explains replication mode and conflict handling, quantifies RPO and RTO, and describes failover including how traffic moves and how the old region rejoins. Interviewers probe: what happens to writes in flight when a region dies, how a user's data follows them, how two regions resolve a conflicting update, and what the latency cost of strong consistency is.

Down the stack

Layer 1The contract

For each data class, state three numbers and one rule. RPO: how much acknowledged data a regional loss can lose (zero for synchronous or quorum replication across regions; seconds for asynchronous). RTO: how long until service resumes elsewhere (seconds for active-active, minutes for active-passive). Read staleness: how old a cross-region read can be (typically under a second to a few seconds of replication lag). Conflict rule: what happens when two regions write the same key concurrently (last-writer-wins, merge or impossible by ownership). Without these, "multi-region" means nothing testable.

Layer 2The mechanism

Asynchronous replication ships a change stream: Postgres streams WAL records to a remote standby, MySQL ships binlog events, DynamoDB global tables replicate item changes, typically within a second, and reconcile concurrent writes with last-writer-wins on an internal timestamp; a strongly consistent read in one region can still return stale data written elsewhere (same AWS page). Cassandra writes to replicas in every datacenter but lets the client choose consistency per request: LOCAL_QUORUM waits only for the local datacenter, EACH_QUORUM waits for a quorum in each (Cassandra docs). Spanner commits via Paxos groups with replicas across regions and uses TrueTime, an API returning an interval [earliest, latest] with bounded clock uncertainty, waiting out that uncertainty before acknowledging a commit so timestamps reflect real-time order. In Google's production the uncertainty is a sawtooth of about 1 to 7 ms, 4 ms most of the time, so commit wait is cheap next to a cross-region round trip (Corbett et al., OSDI 2012). Traffic steering uses DNS with health checks and short TTLs (with resolvers that may ignore them), or anycast addresses announced from every region so routing withdraws a failed region automatically. Home-region routing uses a small, globally replicated directory mapping entity to region, cached at the edge.

Layer 3The machine

Light in fibre covers about 200 km per millisecond, roughly two-thirds of its speed in vacuum, and real paths are longer than great-circle distance: even a perfect New York to London fibre would take 56 ms round trip (Grigorik, HPBN). Typical round trips are on the order of 60 to 80 ms between the US east and west coasts, 70 to 90 ms between the US east coast and western Europe, and 150 ms or more between the US and Asia. A synchronous cross-region commit pays at least one such round trip; a protocol with two phases pays two. Bandwidth costs matter too: cloud providers charge for inter-region transfer per gigabyte, so replicating a 50 MB/s change stream to two other regions is about 8.6 TB per day of billed egress. TCP throughput over a long fat pipe depends on window size: a 150 ms path needs about 19 MB in flight to sustain 1 Gbit/s, so replication links need tuned buffers or many parallel streams.

Why it's built this way

Distance imposes latency that no engineering removes, so synchronous agreement across regions is reserved for data that truly needs it. Regions fail as units (power, networking, control planes, bad deploys), so availability needs copies in independent regions. Replicating asynchronously keeps writes fast but creates a window of possible loss and conflicts, so designs either assign each record a single owner region or choose data types that merge. Failover is risky and rarely exercised, so the best designs make every region serve traffic all the time.

Diagram

flowchart LR
    U1["EU users"] --> GR["Geo DNS or anycast"]
    U2["US users"] --> GR
    GR --> EU["EU region (home for EU users)"]
    GR --> US["US region (home for US users)"]
    EU <-->|"async replication, about 80 ms"| US
    DIR["Global home-region directory"] --- EU
    DIR --- US
    EU -->|"write for US user"| US

Worked example

A messaging app has 60 million users: 45% in Europe, 40% in the Americas, 15% in Asia. It currently runs in one US region, and European users see about 100 ms extra on every API call. The goals are lower latency and surviving a region loss with under 5 seconds of message loss and under 5 minutes of downtime.

The team chooses home regions: each user is assigned to the nearest of three regions at signup. Conversations are homed with the creator's region. Messages for a conversation are written in its home region and asynchronously replicated to the other two, so readers anywhere read locally, with lag usually under a second. A European user sending to a European conversation sees local write latency (about 10 to 20 ms). Sending to an American-homed conversation pays one transatlantic round trip, about 80 ms, which is acceptable for messaging.

Replication volume: 2 billion messages per day at about 1 KB with metadata is 2 TB per day, so about 4 TB per day of cross-region transfer to two peers, a predictable cost line.

Region failure: when the US region fails, the directory marks it down and promotes US-homed conversations to EU and Asia replicas. Asynchronous lag at the moment of failure was under 2 seconds, so a handful of messages may be lost or arrive late when the region returns; the clients still hold unsent messages with idempotency keys and resend them. Clients are redirected by DNS with a 30-second TTL, plus app-level retry to a fallback endpoint list, which handles resolvers that cache longer.

In the wild

Trade-offs

OptionStrengthsWeaknessesChoose when
Active-passiveSimple, no conflictsRemote write latency, minutes of RTO, possible data lossStarting out, single-writer databases
Active-active with home regionsLocal writes, no conflictsRouting directory, cross-region operations, migrationsUsers or tenants with clear locality
Multi-writer with LWWWrites anywhere, simpleSilent lost updatesData where overwrite is acceptable
Multi-writer with CRDTsConverges without lossLimited data types, metadata overheadCounters, sets, collaborative state
Globally consistent databaseSerializable everywhereCross-region write latency, costMoney, inventory, global uniqueness

Pitfalls in production

Leadership lens

Check yourself

  1. Why does active-passive with async replication have a non-zero RPO?

    Show answer

    Writes acknowledged by the primary may not have reached the standby when the primary region fails, so they are lost on promotion.

  2. How do home regions avoid write conflicts?

    Show answer

    Each record has exactly one region that accepts its writes, so concurrent writes to the same record are serialised in that region.

  3. Why does a globally consistent database add latency to writes?

    Show answer

    A commit needs acknowledgement from a majority of replicas, and when they span regions that requires at least one cross-region round trip.

  4. What goes wrong with last-writer-wins when clocks drift?

    Show answer

    The region with the faster clock wins conflicts regardless of real order, silently discarding later updates from other regions.

Sources and further study

Primary

Systems docs

Books

Other curricula

Watch

Free resources

Open in the interactive app: practice, quiz, mock interview →