Active-active vs. active-passive disaster recovery — how do they differ and what's the actual RTO/RPO tradeoff?

#Two numbers before you design anything

Before comparing topologies, pin down the two numbers that actually define a disaster-recovery requirement, because "we need high availability" is not a spec.

RTO (Recovery Time Objective) answers: how long can the system be down before the business is materially harmed? If checkout can be offline for 15 minutes without anyone outside the company noticing, your RTO is 15 minutes. RPO (Recovery Point Objective) answers: how much data can you afford to lose, measured in time? If your last backup or replication checkpoint was 5 minutes before the disaster, and that's acceptable, your RPO is 5 minutes.

These two numbers, not the words "active-active" or "active-passive," are what a disaster-recovery design should be judged against. A beautifully engineered active-active system that still loses 30 seconds of writes on failover has an RPO of 30 seconds — say that number out loud in the design review, not just the topology name.

#Active-passive: one region works, one region waits

In active-passive, one region (the primary) serves all production traffic. A second region (the standby) continuously receives replicated data but serves nothing — it exists purely to be promoted if the primary dies.

The failover sequence is: detect the primary is down (health checks, usually with a delay to avoid flapping on a transient blip), promote the standby to primary (point its database out of read-only mode, update its config), and redirect traffic (DNS cutover or a load-balancer switch). Each of those three steps takes real time — detection alone is often 30-90 seconds if you want to avoid false positives — so a realistic active-passive RTO is measured in minutes, not seconds, even with automation. RPO is bounded by replication lag: if replication is asynchronous (the common case, because synchronous cross-region replication is slow), whatever writes hadn't reached the standby when the primary died are gone.

The appeal is simplicity: one thing writes to the database, so there is no conflict resolution to design, no split-brain to guard against, and the failure mode is well understood. The cost is that the standby region's capacity sits mostly idle, and failover is a discrete, occasionally-rehearsed event rather than something that happens routinely — which means it's also the thing most likely to be broken when you actually need it, because it's the least-exercised code path in the whole system.

#Active-active: both regions work, all the time

In active-active, both regions serve live production traffic simultaneously, and both accept writes.

Because both regions accept writes to the same logical dataset, you now need a conflict-resolution strategy for the case where the same record is modified in both regions before replication catches up: last-write-wins by timestamp, vector clocks, CRDTs for data types that merge cleanly (counters, sets), or application-level merge logic. If a region fails, there is no "promotion" step — the other region was already serving traffic — so RTO for that failed region's users is close to zero (bounded mostly by how fast your router notices and stops sending traffic there). RPO can also approach zero for data that never needed cross-region merging in the first place, but any write that was mid-flight to the failed region at the moment it died is genuinely gone unless it was also synchronously acknowledged elsewhere.

#The tradeoff, side by side

#Choosing between them

The honest interview answer is rarely "always active-active" — that's the answer that sounds sophisticated but ignores cost. Start from the RTO/RPO the business actually needs, check whether the data model can tolerate multi-writer conflicts at all (a strict ledger with double-entry accounting invariants is a much harder active-active candidate than a social feed's like-counter), and only then pick the topology. Many systems land on a hybrid: active-active for stateless, idempotent?, easily-mergeable data (sessions, caches, read-heavy catalogs) and active-passive for the small slice of strongly consistent, hard-to-merge data (payments, inventory ledgers).

🧠 Check your understanding
0/2 · 0/2 answered
1. A payments ledger needs strict consistency and cannot tolerate conflicting writes being merged automatically. Which DR topology fits it best?
Active-active with last-write-wins conflict resolutionMulti-master with vector clocksActive-passive, since a single writer avoids the conflict problem entirelyActive-active with CRDTs
2. What primarily bounds the RPO in an active-passive setup using asynchronous replication?
The number of standby regions provisionedHow much data had not yet reached the standby when the primary failedThe health-check interval of the load balancerThe DNS TTL of the domain