9
Architecture
Active-active vs active-passive across two data centres
Availability ↔ Operational complexity
Context
Keep a regulated order platform running if one of two data centres fails.
We run an order platform in two on-prem data centres 40 km apart. Regulators want an RTO under 5 minutes and zero data loss.
Option A: active-active, both sites take traffic, so we use all capacity and a site loss just sheds half the load.
Option B: active-passive, a hot standby with synchronous replication, promoted on failure.
At 40 km synchronous replication is affordable (~0.5 ms). Is active-active worth the complexity?
Constraints
- Sites
- 2 on-prem DCs, 40 km apart
- RTO / RPO
- < 5 min / zero data loss
- Database
- PostgreSQL, synchronous replication possible
Active-active (both sites serve traffic)vsActive-passive (hot standby)
Community verdict
Active-active (both sites serve traffic) 33%Active-passive (hot standby) 67%
9 engineers · 5 opinions
With these constraints, what would you choose?
One choice per engineer. You can change it any time.
Active-active (both sites serve traffic)
Active-passive (hot standby)
Simplicity →
Trade-offs
Dimensions
Active-active (both sites serve traffic)Active-passive (hot standby)out of 5
- Availability
- 5Active-active (both sites serve traffic) scores 5 of 54Active-passive (hot standby) scores 4 of 5
- Simplicity
- 2Active-active (both sites serve traffic) scores 2 of 54Active-passive (hot standby) scores 4 of 5
- Data consistency
Community discussion
5 comments
Have you made this decision in production? Share your reasoning.
Sign in to commentSplit the question. Stateless tiers can be active-active cheaply. The database is where active-active hurts: two writable primaries means conflict resolution, and with zero RPO you want one writer.
So: app tiers active-active, PostgreSQL active-passive with synchronous replication and automated, rehearsed promotion.
That is the shape we are converging on. The DB promotion is the part we will drill monthly.
Make sure fencing is solid: a split brain with two primaries writing orders is far worse than five minutes of downtime.
A passive site rots. Config drifts, capacity gets borrowed, and the failover you never run fails when you need it. Serving real traffic from both sites is the only test that never lies.
Or run regular failovers in production. Same truth, less complexity.