Multi-Region Active-Active

Overview

In active-active, every region serves production traffic and can accept writes. Capacity is shared, and losing a region means redirecting its users rather than activating a cold site.

Data is the hard part. Options include a globally distributed database with tunable consistency, per-entity home regions with routed writes, and conflict-free replicated data types for counters and sets. Each shifts the trade-off between latency, consistency, and operational complexity.

How it works

Global routing sends users to the nearest healthy region; data replicates asynchronously between regions.

            Global DNS / anycast (latency + health)
           /                \
    Region A (EU)  <==async==>  Region B (US)
    app + DB writes             app + DB writes
Rule: each entity has a home region, or merge via CRDT / LWW

Plan capacity for the failure case. With three regions, each should carry at most about sixty-six percent of its capacity in steady state to absorb a lost neighbor. Test failover with game days that shift traffic and verify that autoscaling, quotas, and caches keep up.

Pitfalls

• Provisioning each region at only half the needed capacity, so one failure overloads the other
• Using last-writer-wins on data where lost updates matter, such as balances
• Shared global dependencies like a single auth database that remain single-region
• Never drilling region evacuation until a real incident

Key takeaways

• Decide conflict handling before writing code
• Size each region to survive the loss of another
• Eliminate hidden single-region dependencies
• Practice regional drains routinely