The architectural choice is presented as binary; the practical answer is "depends on the workload." The patterns that earn their place and the failure modes we've hit.
Multi-Region — Active-Active vs Active-Passive, And What We Actually Run
The textbook answer to "how do I survive a region outage?" is "go multi-region." The textbook answer to "active-active vs active-passive?" is usually a flowchart. The reality is messier — every component in your stack makes a different choice, and the architectural simplicity of one pattern doesn't help when your database can't follow it.
We run a multi-region production environment across two AWS regions. Some pieces are active-active; some are active-passive; some are single-region. This is the framework we use and the failures that shaped it.
Active-Active. All regions serve traffic simultaneously. Each region has the full stack, capable of handling all traffic on its own. Traffic is routed by latency, by tenant, or by round-robin. Region failure = automatic failover, often invisible to users.
Active-Passive. One region serves all traffic. The other is a standby, kept in sync but not serving. Region failure = controlled failover (manual or automated) to the passive region.
Active-active is more resilient, more expensive, more complex. Active-passive is cheaper, simpler, but slower to recover.
Components where active-active makes sense:
Stateless services (compute). Easy. Run identical service deployments in both regions; the load balancer routes traffic. No coordination needed. A region going down just means traffic shifts.
Read-heavy data with eventual consistency. Cached reads, search indexes, CDN. Replicate to both regions; clients read locally. Slight staleness OK.
Geo-distributed data. When users in one region's data primarily lives in that region (think: GDPR-required regional data residency), each region is largely independent and active-active is natural.
Stateless event consumers (with idempotency). Both regions consume from the same event source; idempotent processing means double-delivery is benign.
For these, active-active is straightforward and adds resilience.
The Postgres-shaped problem. Active-active relational databases are operationally painful:
- Multi-master Postgres (BDR, Patroni multi-master) exists but conflict resolution is application-dependent. Two writes to the same row in different regions = which wins?
- Aurora Global Database does cross-region replication but the secondary is read-only. Writes go to the primary region.
- CockroachDB / Spanner / Yugabyte are designed for active-active globally but are different databases — moving to them is a re-architecture.
For most teams running standard Postgres / MySQL, the database is active-passive even if everything else is active-active. Writes go to the primary region; reads can be local; failover is manual or scripted.
We're in this camp. Postgres is active-passive (primary in us-east-1, replica in us-west-2). Application is active-active in front of it (both regions write to the same Postgres in us-east-1). Cross-region database latency adds ~70ms to write paths in us-west-2; we live with it.
| Component | Pattern | Notes |
|---|
| Web tier (stateless) | Active-active | Independent in each region |
| API tier (stateless) | Active-active | Independent in each region |
| Postgres (primary DB) | Active-passive | Primary in us-east-1; warm standby in us-west-2 |
| Read replicas | Active-active | One per region; reads served locally |
| Redis (cache) | Per-region active | Each region runs its own cache; no cross-region replication |
| S3 (storage) | Active-active | Cross-region replication; clients write to local |
| Kafka | Active-passive | Primary cluster in one region; mirror in other |
| Search (Elasticsearch) | Active-active | Index in both regions; writes dual-routed |
The pattern: stateless and eventually-consistent things go active-active. Strongly-consistent stateful things go active-passive. Failover for the active-passive components is the disaster recovery exercise.
Active-active sounds great until you think about consistency:
- Concurrent writes to the same data. Two users in two regions update the same row at the same time. Which wins?
- Read-after-write. A user writes in
us-east-1, then reads. If their read goes to us-west-2 and replication is delayed, they see stale data.
- Time skew. Region clocks aren't perfectly synced. Sub-second consistency is hard to reason about.
Resolutions exist (CRDTs, vector clocks, last-write-wins, application-level conflict resolution), but each is operational complexity and possible user-visible surprise. We avoided the problem by keeping our write-path active-passive.
Active-passive is only valuable if failover actually works. We test ours quarterly.
The exercise:
- Simulate the primary region being unreachable (route 53 weight = 0).
- Promote the passive Postgres to primary.
- Update application config to point at the new primary.
- Verify the new primary is serving writes.
- Restore the original region.
- Re-promote, switch back.
Total exercise time: ~2 hours. Real downtime if we did this in anger: ~10 minutes if we move fast.
What we learn every time:
- Some config still hard-codes the old primary's hostname. Found it twice in three exercises.
- DNS TTL matters. We've got it down to 30 seconds.
- Connection pools cache the wrong host. We added explicit pool invalidation.
- Replication lag at failover means data loss; how much is OK?
The discipline of doing the exercise is what turns active-passive from "we have a standby" to "we can actually fail over." Active-passive without exercise is theater.
Cross-region latency. ~70ms between us-east-1 and us-west-2. Every cross-region call (web tier in us-west-2 writing to Postgres in us-east-1) adds that. It compounds with N calls per request. Architect around it: batch writes, use local caches.
Asymmetric failure modes. A region rarely fails completely. Often a single AZ degrades, or a specific service has issues. Multi-region helps with full-region outages; it doesn't help with partial degradation. Some of our worst incidents have been partial.
Cost. Multi-region roughly doubles infrastructure cost. The cost is justified for tier-1 user-facing services; less so for internal tools.
Operational complexity. Two of everything. Two sets of dashboards, two sets of alerts, two deployment targets. Operational surface area grows.
Replication-lag-triggered data loss. Active-passive failover with non-zero replication lag means some writes from before the failover are lost. We've held data loss under 5 seconds; getting to 0 requires synchronous replication, which costs latency on every write.
Honest list:
- Startups / small ops teams. Multi-region doubles your ops load. Until you have a team that can sustain it, single-region with strong backups is more resilient than poorly-operated multi-region.
- Internal tools. A dashboard going down for an hour during a region outage isn't a business issue.
- Workloads where DR can be slow. If "we can restore from backup in 4 hours" is acceptable, you don't need multi-region — you need good backups and tested restore procedures.
We have plenty of services that are single-region. The multi-region investment is reserved for the user-facing critical path.
Active-active is mostly active-passive in disguise. Once you trace any active-active design, there's a stateful component somewhere that's actually active-passive. The "active-active" label often applies only to the stateless tier.
The bigger reliability win is intra-region. Most outages we've seen are AZ-level, not region-level. Multi-AZ deployments within a region catch most cases at a fraction of the multi-region cost. Multi-region is for the very tail.
Disaster recovery testing is harder than building DR. Standing up the standby region is one project. Running quarterly exercises that prove it works is forever.
Multi-region is one of those decisions where the architectural choice (active-active vs active-passive) is the easy part. The hard part is operating it: failover discipline, drift detection, the second of everything. Be honest about whether the resilience pays for the complexity. For us, on the user-facing critical path, it does. Elsewhere, it doesn't.
