System Design: Multi-Region Architecture — Active-Active, Data Replication, and Latency Routing

Why Multi-Region?

A single-region architecture has three critical weaknesses: latency (a user in Tokyo hitting servers in us-east-1 has ~150ms baseline RTT), availability (a regional AWS outage takes down your entire service), and compliance (GDPR and other regulations require data to remain in specific geographies). Multi-region solves all three but introduces distributed systems complexity: you must decide how to route users, how to replicate data across regions, and how to handle write conflicts. The patterns below are the standard answers in system design interviews at companies like Google, Meta, Stripe, and Cloudflare.

Active-Passive vs Active-Active

Active-Passive (warm standby): one region handles all traffic (primary); the other is on standby, receiving replicated data but not serving requests. Failover: when the primary goes down, DNS switches traffic to the standby (TTL matters — keep DNS TTL at 60s). Recovery Time Objective (RTO): time to fail over, typically 1-5 minutes. Recovery Point Objective (RPO): data loss on failover, equal to the replication lag (typically seconds). Suitable for: global consistency requirements, apps that cannot tolerate write conflicts. Active-Active: both (all) regions serve traffic and accept writes. No failover needed — traffic shifts automatically. Zero RTO. But: you must handle write conflicts (two regions update the same record concurrently). Approaches: Last-writer-wins (LWW): use timestamps; accept the most recent write. Risk: clock skew. CRDT (Conflict-free Replicated Data Type): data structures that merge automatically (counters, sets). Suitable for: likes, view counts. Region-pinning: route each user to a “home” region; writes in that region only. Other regions are read replicas. Active-Active with region-pinning is the most practical pattern for user-data systems.

Data Replication

Database replication across regions: synchronous replication: each write is committed only after all replicas confirm. Zero RPO but high write latency (write + cross-region RTT). Only viable for critical data (financial transactions) where data loss is unacceptable. Asynchronous replication: write commits locally; replication happens in the background. Low write latency but non-zero RPO (seconds of potential data loss). Standard for user-generated content. Multi-master replication (CockroachDB, Spanner, DynamoDB Global Tables): the database handles conflict resolution internally. CockroachDB uses a Raft consensus protocol per range; writes have ~30-100ms added latency for cross-region consensus. Google Spanner uses TrueTime (atomic clocks + GPS) for globally consistent timestamps. Suitable for global financial apps requiring ACID guarantees across regions. Cache replication: CDN handles static assets automatically. For dynamic data cached in Redis: use Redis Cluster or a pub/sub invalidation pattern. On write in region A: publish an invalidation event to a global message bus (Kafka); all regions consume and evict the key from their local cache.

Latency-Based Routing

Route each user to the nearest/lowest-latency region. Mechanisms: DNS latency-based routing (Route 53, Cloudflare): the DNS resolver returns different IP addresses based on the client’s geographic location. The client connects to the nearest PoP. Anycast routing: the same IP address is announced from multiple regions; BGP routing automatically directs packets to the nearest datacenter. Used by Cloudflare for its global network. GeoDNS: route based on IP geolocation lookup. Less accurate than latency-based but simpler. The edge/load balancer layer (e.g., Cloudflare Workers, AWS CloudFront, Fastly Compute@Edge) can inspect the request, determine the best backend region, and either serve from cache or proxy to the appropriate region. Health checks: the routing layer continuously pings each region. If a health check fails: traffic is shifted away from that region within seconds (before DNS TTL expires).

Cross-Region Consistency Patterns

Read-your-writes consistency: after a user writes, ensure they see their own write (not stale data from a replica). Solutions: sticky sessions (route the user to their home region for reads immediately after writes), version tokens (include a version number in the response; reads include min_version, the replica waits until it has caught up to that version), write-through (write to global store directly, read from cache only after confirming replication). Distributed transactions: avoid if possible (high latency). Use sagas (choreography or orchestration pattern) for multi-step operations. Each step publishes an event; compensating transactions handle rollback. Saga coordinator tracks the state of each step. Idempotency: every cross-region operation must be idempotent (safe to retry). Use idempotency keys (UUID per request) checked in an idempotency_keys table at each region. If the key already exists: return the stored result without re-executing.

Interview Tips

Start with active-passive if the interviewer doesn’t specify — it’s simpler and often sufficient.
Be explicit about RPO vs RTO tradeoffs when choosing synchronous vs asynchronous replication.
Region-pinning (each user has a home region) is the practical answer for user-data active-active.
Idempotency keys and sagas are the standard answers for distributed transactions across regions.

{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”What is the difference between active-passive and active-active multi-region architecture?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Active-passive has one primary region serving all traffic while a standby region receives replicated data but is idle. On primary failure, DNS failover directs traffic to the standby — typically 1-5 minutes RTO. Active-active has multiple regions simultaneously serving traffic and accepting writes, giving zero RTO, but requires conflict resolution strategies for concurrent writes to the same data.”}},{“@type”:”Question”,”name”:”What is RPO vs RTO and how do they affect replication strategy?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”RPO (Recovery Point Objective) is the maximum acceptable data loss — how far back in time you can recover to. RTO (Recovery Time Objective) is how long recovery takes. Synchronous replication achieves near-zero RPO (no data loss) but increases write latency by the cross-region RTT. Asynchronous replication has low write latency but non-zero RPO (seconds of potential loss on failure).”}},{“@type”:”Question”,”name”:”How does region-pinning work for active-active user data?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Each user is assigned a home region (based on their sign-up location or current location). Writes go to the home region only. Other regions act as read replicas for that user's data. On read, route to the nearest region; if the user just wrote, route to the home region to ensure read-your-writes consistency. This avoids cross-region write conflicts entirely.”}},{“@type”:”Question”,”name”:”How do you handle distributed transactions across regions without 2PC?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Use the Saga pattern: break the transaction into a sequence of local transactions, each publishing an event on success. If a step fails, compensating transactions undo previous steps. The saga coordinator (or choreography via events) tracks overall state. Each step must be idempotent (safe to retry) using idempotency keys checked in a local table.”}},{“@type”:”Question”,”name”:”How does anycast routing differ from DNS-based geo-routing?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”With anycast, the same IP address is advertised from multiple datacenters via BGP. Routers automatically direct packets to the nearest datacenter based on network topology — no DNS lookup needed. This is faster than DNS geo-routing (no extra DNS round trip) and more resilient (BGP reconverges in seconds if a datacenter goes down). Cloudflare and major CDNs use anycast for their global networks.”}}]}