Multi-Region Active-Active Deployment: Being Everywhere at Once

The Netflix Christmas Eve Outage That Changed Everything

On Christmas Eve 2012, an AWS outage in US-East-1 took down Netflix, Instagram, and Vine for hours. Netflix decided this would never happen again. They built active-active multi-region: traffic served simultaneously from three AWS regions. If US-East-1 disappears entirely, US-West-2 absorbs the load within seconds. No failover pause, no downtime, no pager at 3am. Today, most large-scale services (Uber, Slack, Stripe) run active-active across regions.

Active-Active vs Active-Passive

Deployment Models Compared:

Active-Passive:
  [US-East] ACTIVE     [EU-West] STANDBY (idle)
  All traffic ------>  Replicated data (read-only)
  Failure? Manual/auto failover (2-30 min downtime)
  Cost: pay for idle standby
  Complexity: moderate

Active-Active:
  [US-East] ACTIVE     [EU-West] ACTIVE
  US users ------>     EU users ------>
  Both handle live traffic simultaneously
  Failure? Other region absorbs load instantly
  Cost: both regions fully utilized
  Complexity: HIGH (write conflicts)

Why active-active is hard:
  User A in Tokyo: UPDATE profile SET name='Alice'
  User B in Frankfurt: UPDATE profile SET name='Alicia'
  Both writes succeed in their local database.
  Now you have two competing versions.
  Which one wins?

Data Replication Across Regions

The core challenge of active-active is getting data from one region to another fast enough to be useful. Cross-region replication adds 100-200ms of latency per hop (US-East to EU-West is roughly 80ms one way). Synchronous replication across regions would double every write latency, which is unacceptable for user-facing operations. So most active-active systems use asynchronous replication: writes commit locally in milliseconds, then replicate to other regions in the background. The trade-off is a replication lag window where the two regions have slightly different data.

Write Conflict Resolution

Conflict Resolution Strategies:

Strategy          How It Works                   Trade-off
-----------       ---------------------------    -------------------
Last-Write-Wins   Highest timestamp wins         Clock skew risk
(LWW)             Simple, lossy                  May drop valid writes

Home Region       Each user assigned a           Cross-region writes
Routing           'home' region for writes       route to home region
                  Reads from local replica       Higher write latency

CRDTs             Data structures that           Only works for specific
                  auto-merge without             data types (counters,
                  coordination                   sets, not arbitrary)

Application       Surface conflicts to app       Most flexible but
Merging           layer (like git merge)         most complex to build

Netflix approach: home-region routing
  - User's write region = closest AWS region
  - Profile writes go to home region
  - All regions serve reads from local replica
  - Replication lag: <1 second cross-region

Regional Failover: The Hard Part

When a region fails, traffic must shift to surviving regions. DNS-based failover (Route 53 health checks) takes 30-60 seconds because of DNS TTL propagation. For faster failover, use a global load balancer (AWS Global Accelerator, Cloudflare) that routes at the anycast IP level - failover in under 10 seconds. The real complexity is capacity planning: each region must have enough headroom to absorb another region's traffic during a failure. If US-East handles 60% and EU-West handles 40%, then US-East needs capacity for 100% during an EU-West outage, not just 60%.

Interview Tip

Multi-region active-active is about reads AND writes from every region. The easy part is reads (replicate everywhere). The hard part is write conflicts. Lead with home-region routing (each user's writes go to one region, reads from any) as the practical default. Mention CRDTs for specific data types and LWW as the simplest-but-lossy option. Always quantify replication lag (~100-200ms cross-region).

Key Takeaway

Active-active multi-region eliminates single-region failure as a downtime risk, but introduces write conflict complexity. Use home-region routing to avoid conflicts for most operations, asynchronous replication for low write latency, and plan capacity so each region can absorb a failed region's traffic. DNS failover is slow - use global load balancers for sub-10-second failover.