Multi-Region — Active-Active vs Active-Passive

One AWS region fails — your service is down for 30 minutes. Multi-region deployment fixes this, but how? You can run the second region passively (cold or warm standby that takes traffic only on disaster) or actively (both regions serve users continuously). The choice cascades through every architectural decision: replication strategy, consistency model, DNS, costs.

Active-active sounds obviously better — until you confront writes-from-two-places, conflict resolution, and 2× the infra bill. Most teams who say they want active-active actually want the easier option done well.

Region A serves all traffic. Region B has identical infrastructure but no traffic — async replication keeps its data current. On disaster:

1. Health check fails (Route 53 or external monitor).
2. DNS updated to point to region B (or anycast routing kicks in).
3. Region B's database is promoted from replica to primary.
4. Service comes online. RTO: 5-30 min depending on automation.

Wins: no write conflicts — only one region accepts writes at a time. Standard relational databases work fine. Conceptually simple; most engineering teams can ship this.

Catches: warm standby may not actually work when needed (untested code paths). Async replication means RPO > 0 — some recent writes can be lost. Failback (returning to A after recovery) is operationally tricky.

Both regions serve. Users in EU hit EU region; users in US hit US region. Lower latency for everyone. Region failure is invisible to most users.

The hard part: writes happen in both regions simultaneously. Conflict resolution becomes mandatory. Three approaches:

• Sharded by user/region — user "always lives" in one region. Writes for user X always go to that region. Other region holds a replica for reads. Reduces conflicts to near-zero. Practical default.
• CRDTs / multi-master with merge — accept that conflicts happen, design data types that merge automatically. Vector clocks + LWW or richer CRDTs. Works for some data shapes (counters, sets); not for ordered transactions.
• Sync cross-region writes — every write coordinates across regions before commit. Paxos/Raft across regions. Spanner does this. Latency cost: 100-200ms per write.

Picking depends on workload. Banking can't tolerate conflict resolution → sync sharded by account. Social networks can → user-level sharding with CRDT counters for likes. Cassandra-backed services use LWW + accept some lost writes.

• Active-passive for: most B2B SaaS, internal tools, anything where 15 min downtime is OK if rare. Lower complexity, lower cost.
• Active-active sharded for: global consumer apps with locality (Slack workspaces, Dropbox accounts, Notion teams). Mostly each user lives in one region.
• Active-active CRDT for: counters, dashboards, soft state. Eventual consistency tolerated.
• Active-active synchronous for: financial systems where consistency > availability. Pay the latency.

WhatsApp uses active-active sharded by user_id. News feed uses active-active for reads, primary-region for writes. Payment gateway runs active-active synchronous for the ledger. E-commerce typically warm-passive — failover acceptable if rare.