Multi-Region Architecture: Routing, Data & Failover

Multi-Region Application Architecture

Cloud regions fail rarely, but they do fail — and when a whole region has trouble, every service deployed only there goes down together. Regions also sit far from some users, adding latency, and laws or contracts may require that some customers' data stays in a particular geography. Running in multiple regions addresses all three: availability, latency, and data residency.

It is also one of the most expensive and complex steps in system design. The hard part is not running application servers in two places; it is data. Writes must go somewhere, replication takes time, and the speed of light means regions cannot agree instantly. Every multi-region design is a set of explicit choices about how much data you can lose, how long recovery may take, who can write where, and how much you are willing to pay.

TL;DR

Decide why first: availability, latency, or residency lead to different designs.
Set RPO (acceptable data loss) and RTO (acceptable downtime) per service; they determine the pattern.
Patterns range from backup and restore through pilot light and warm standby to active-active.
Home-region partitioning — each user or tenant lives in one region — avoids most write conflicts.
Routing uses DNS (latency or failover records), anycast, or global load balancers, with health checks.
Asynchronous replication risks losing recent writes; synchronous or consensus-based databases add write latency. Test failover regularly.

Quick Example

Latency-based DNS routing with health checks across two regions (Terraform, Amazon Route 53):

Routing requests to a tenant's home region, so each tenant's writes happen in exactly one place:

Core Concepts

Why Go Multi-Region

Many systems need only one of these. A CDN and edge caching solve much of the latency problem without moving databases. See CDN and Edge Computing.

Recovery Objectives

Recovery point objective (RPO) is how much recent data you can afford to lose; recovery time objective (RTO) is how long you can be down. A ledger may need RPO near zero; an analytics pipeline might accept hours. Set objectives per service, because applying the strictest one everywhere is ruinously expensive. See Disaster Recovery Planning.

Patterns

Data Strategies

The CAP theorem's tradeoff becomes concrete here: during a network partition between regions, a system either rejects some writes (consistency) or accepts writes that may conflict (availability). See CAP Theorem and Database Replication.

Routing Traffic

DNS with latency, geolocation, or failover policies and health checks; failover speed depends on TTLs and client caching.
Anycast and global load balancers route to the nearest healthy region at the network level, failing over faster than DNS.
Application routing forwards requests for a tenant to its home region, as in the quick example.

See Load Balancing.

Failover

Decide in advance who or what triggers failover. Automatic failover reacts fast but can flap or fail over on false alarms; manual failover is slower but deliberate. Either way:

Promote the standby database only when the old primary is fenced (cannot accept writes), to avoid split brain.
Account for replication lag: writes not yet replicated are lost or must be reconciled later.
Fail over dependencies too — secrets, queues, caches, identity providers, third-party allowlists.
Plan failback: returning to the original region is a second migration.

Test regularly with game days and scheduled regional evacuations. A failover that has never been exercised usually does not work when needed. See High Availability.

Cost and Complexity

Multi-region roughly multiplies infrastructure, adds cross-region data transfer charges, and increases deployment, monitoring, and on-call complexity. Every component — including internal tools, CI runners, and observability — needs a regional story. Start with the services whose downtime costs the most, and use cheaper patterns for the rest.

Best Practices

Set RPO and RTO per Service

Match the pattern to each service's real business needs instead of one design for everything.

Prefer Partitioning Over Conflict Resolution

Home regions avoid write conflicts and satisfy residency; use multi-primary writes only where needed.

Make Regions Independent

Avoid hidden cross-region dependencies, such as a single-region identity provider, secrets store, or deploy pipeline.

Rehearse Failover

Run scheduled failover tests, measure actual RTO and RPO, and fix what breaks.

Common Mistakes

Active-Active Without a Conflict Strategy

Hidden Single-Region Dependencies

Untested Failover

FAQ

Do I need a multi-region architecture?

Only if a regional outage, distant users, or data residency requirements justify the cost. Many applications are well served by multiple availability zones in one region, a CDN, and good backups.

What is the difference between active-passive and active-active?

In active-passive, one region serves traffic while another stands ready; in active-active, multiple regions serve traffic simultaneously, which improves latency and failover time but complicates data consistency.

What are RPO and RTO?

Recovery point objective is the maximum acceptable data loss, measured in time; recovery time objective is the maximum acceptable time to restore service after a failure.

How do I avoid write conflicts across regions?

Assign each user or tenant a home region where their writes happen, use a globally consistent database that coordinates writes, or design conflict resolution such as CRDTs for data that must accept concurrent writes.

Why is DNS failover slow?

Clients and resolvers cache DNS answers for the TTL and sometimes longer, so some traffic continues to reach a failed region. Anycast or global load balancers fail over faster.