Active-Active vs Active-Passive
- Pradeep P
- 3 days ago
- 3 min read
Layer 5 · Post 11 of 12
← Previous: Multi-region Architecture → Next: Disaster Recovery
Layer 5 — Modern infrastructure · Post 61 of 88
Active-active serves traffic from multiple sites at once. Active-passive keeps a standby ready. The difference is latency, cost, and conflict handling.
What you'll learn
What "active" means for compute versus for the database
When standby (active-passive) is the honest design
Why two writers mean conflict rules, not just two clusters
The idea in one minute
You have two sites (regions or DCs).
Active-passive: site A takes all user traffic. Site B is warm or cold. On disaster (or planned failover), you promote B. Users of A were fine until A died; then you pay failover time.
Active-active: both sites take traffic at once. Users go to a nearby healthy site. You pay complexity on every write.
Active-passive: Users --> [ A LIVE ] [ B STANDBY ] Active-active: Users --> [ A LIVE ] and [ B LIVE ]
People mix this up with multi-AZ. Two AZs both serving is active-active inside a region. This post is usually about sites that can fail independently.
Why it matters
Interview prompts that say "99.99% and a region can vanish" are asking which of these you picked and what happens to in-flight writes.
Active-active sounds like the grown-up answer. For a ledger, two concurrent writers without a story is how you double-charge. Active-passive with a tested failover often beats an untested dual-write mesh.
How it works
Active-passive flavors
Cold: B has backups and IaC. Restore takes hours. Cheap. High RTO.
Pilot light: B runs a tiny control plane and data replica; you scale out on failover.
Warm: B runs almost full capacity but gets no (or synthetic) traffic. Failover is DNS/Anycast flip + promote DB. You pay for idle capacity.
Replication is usually async primary → standby. RPO is the lag. Failover is: stop writes to A (if you can), promote B, point DNS, invalidate clients.
Active-active flavors
Stateless active-active + single writer DB: both regions run apps; all writes go home to one primary. Easy. The DB is still active-passive. Honest name: active-active compute.
Active-active data: both regions accept writes.
Home region / sharding: user or tenant pinned. No conflicts. Failover of a home is still a promotion.
Conflict resolution: last-write-wins, merge, or CRDTs. Shopping carts can merge; bank balances cannot LWW.
Sync cross-region commit: both sites confirm. Latency is ocean-sized. You chose consistency over local RTT.
Split brain
Both sites think they are primary. Two inventories sell the same SKU. Fencing, quorum, and "only promote with human or consensus" exist for this. Failover runbooks that skip fencing are how you get two truths.
A simple example
A content site: active-active compute, reads from local replicas, writes to one CMS primary. A region loss drops that region's readers to the other via DNS. Editors might wait. That is a fine 99.9% design.
A wallet: active-passive. Primary in us-east-1, async replica in us-west-2. On region loss you promote, accept seconds of lost un-replicated writes if the SLA says so, or you used sync replication and paid latency every day. You do not LWW two balances.
Common mistakes
Calling it active-active because the standby is running. If users never hit it, it is warm passive. Say that. The failover path is still unproven until you fail over.
Last-write-wins on money or inventory. Conflicts need business rules, not timestamps.
Forgetting sessions and caches. Sticky sessions to region A, failover to B, empty cache, thundering herd. Design session store location.
Never failing over on purpose. The first real failover is not the time to learn DNS TTLs. Game days exist.
How this shows up in real systems
DNS failover, Global Accelerator, Traffic Director: the flip or the split.
RDS Multi-AZ vs Aurora Global vs DynamoDB global tables: products map onto these modes — read the write path, not the brochure.
Recap
Active-passive: one site serves; the other waits. Simpler data, real failover work.
Active-active: both serve; writes need pinning or conflict rules.
Name honestly whether compute, data, or both are dual-active.
Architecture without a timed recovery plan is a diagram. Next: disaster recovery as RPO, RTO, and practice.
Layer 5 · Post 11 of 12
← Previous: Multi-region Architecture → Next: Disaster Recovery
Comments