Multi-Region Architecture

A multi-region system runs in two or more geographic cloud regions. The motivation is usually one or both of:

• Resilience: a region outage doesn't take down the service.
• Latency: users in each geography hit a local region, with network latency measured in ms instead of hundreds of ms.

Two topologies dominate:

• Active-passive: one region serves all traffic; the other is a standby that takes over on failure. Simpler. Lower cost. Higher RTO/RPO on failover.
• Active-active: both regions serve live traffic simultaneously. More complex. Higher cost. Lower RTO/RPO. Better latency for global users.

The trade-offs in multi-region are mostly about data, not compute. Replicating stateful services across regions is hard; replicating stateless services is easy.

Stateless services are easy to multi-region: deploy the same code to multiple regions, put a global load balancer (Cloudflare, Route 53, Cloud Load Balancing) in front, and route users to the nearest healthy region. No replication needed.

Stateful services are hard. A database in us-east-1 doesn't automatically exist in eu-west-1; you have to replicate it. The replication choices:

• Asynchronous: writes commit locally, replicate later. Fast writes, but failover can lose data (RPO = lag, often seconds). The replica can also serve stale reads.
• Synchronous: writes wait for the replica to acknowledge. Zero data loss, but every write pays cross-region latency (50-100ms+). Too slow for many workloads.
• Conflict resolution: in active-active, both regions can accept writes to the same key. You need last-writer-wins (clock-based, error-prone), CRDTs (data-type-specific, complex), or application-level merge logic.

This is why most active-active systems are sharded by region: each user's data lives in one region, replicated to others as a standby. No write conflicts because each user writes to one region. Read replicas serve other regions for low-latency reads.

How does traffic get to the right region? Three patterns:

• DNS-based routing (Route 53 latency routing, Cloudflare load balancing): the user's DNS lookup returns the IP of the nearest region. Simple, but DNS caching means failover takes the TTL (often 60s).
• Anycast IP: the same IP is announced from multiple regions; BGP routes the user to the nearest. Faster failover (no DNS), but harder to debug.
• Global proxy / CDN: Cloudflare, Fastly, or a global Layer 7 LB inspects the request and routes it. Most flexible — can route by user, by health, by content.

Failover works by removing the unhealthy region from the routing. The challenge is detecting regional failure: a region that's slow (not down) is harder to handle than one that's down. Most teams use a combination of health checks + manual approval for failover, to avoid false positives that route global traffic away from a healthy region.

Multi-region isn't free. The costs add up:

• Compute: 2x the instances (or more, for active-active).
• Replication bandwidth: cross-region data transfer is metered and expensive at scale. Streaming changelogs across regions can be a meaningful fraction of cloud bill.
• Storage: each region has its own copy.
• Operational complexity: deploying to multiple regions, monitoring both, debugging cross-region issues.
• Engineering complexity: handling partial failures (one region up, one down), conflict resolution, eventual consistency.

A common pattern: don't go multi-region until you've exhausted multi-AZ. Multi-AZ gives you single-region resilience cheaply. Multi-region is for when multi-AZ isn't enough — either because of latency to global users or because a single-region outage is unacceptable to the business.

Mental model. Think of Multi-Region Architecture as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does Multi-Region Architecture mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”

Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.

Answer this without notes: When would you choose Multi-Region Architecture, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.

Numerical sanity check

Back-of-the-envelope reasoning beats fake precision. State your traffic, payload, concurrency and growth assumptions explicitly, then calculate enough to know whether the current architecture is orders of magnitude away from the target.