Side by side
| Dimension | Active-active | Active-passive |
|---|---|---|
| Normal traffic | Multiple instances or regions serve traffic | Primary serves; standby waits |
| Failure response | Redirect traffic to healthy capacity | Promote standby and redirect traffic |
| Write ownership | Single-writer, partitioned, or multi-writer | Usually one active writer per scope |
| Data conflicts | Possible with concurrent multi-region writes | Usually avoided through exclusive ownership |
| User latency | Local serving possible; writes depend on coordination | Remote users may reach the primary region |
| Recovery time | Depends on detection, routing, and dependencies | Also includes standby readiness and promotion |
| Potential data loss | Depends on replication and acknowledgment policy | Depends on replication and promotion policy |
| Capacity and cost | Serving capacity still needs failure headroom | Standby capacity trades cost against recovery speed |
| Operational burden | Routing, partial failures, and data coordination | Promotion, fencing, and tested failback |
The differences that matter
The label applies to a specific tier and failure scope. Two regions can both run active API servers while all writes go to one database leader. That is active-active compute with single-writer storage, not a multi-writer database. State which requests each region can complete independently before claiming regional resilience.
Active-active does not require accepting conflicting writes. You can assign each tenant or shard a home region, route writes to one leader, or coordinate writes through a quorum. These choices trade local write latency and partition availability for simpler invariants. If both regions independently accept updates to the same record, define conflict resolution and explain which business rules it preserves.
Active-passive makes promotion part of the recovery path. Detection, replication catch-up, fencing the old primary, promotion, and routing all affect recovery time. Active-active can avoid some promotion work, but still needs failure detection and traffic rerouting. An active API region that depends on a failed database region cannot keep completing writes merely because its servers are running.
Neither topology determines durability. With asynchronous replication, a promoted standby can lack acknowledged writes; an active-active system can also lose locally acknowledged writes if that region fails before replication. Synchronous replication can reduce that risk, but adds coordination latency and may stop writes when the required replicas are unreachable.
Compare provisioned capacity under failure, not just normal utilization. Active-active uses both regions during normal operation, but survivors need enough headroom or an explicit load-shedding policy. Active-passive can use a smaller standby to save resources, at the cost of scaling time and possibly reduced service during recovery. Both need failover drills and a safe failback procedure.
Choose Active-active when
- Users are geographically distributed, and local reads or independently owned regional writes materially improve latency.
- Your recovery target leaves little room for standby startup or promotion, and each surviving region can serve the required workload.
- The workload tolerates eventual consistency, or you have explicit write ownership or coordination that preserves its invariants.
- You can operate cross-region routing, replication monitoring, failure testing, and recovery without relying on manual improvisation.
Choose Active-passive when
- One authoritative writer makes inventory, ledger, or workflow invariants easier to enforce, and a bounded promotion delay is acceptable.
- The workload is concentrated in one region, so simultaneous regional serving offers limited latency benefit.
- You want a simpler normal-operation model and can invest in reliable fencing, standby readiness, and automated recovery.
- You accept a longer recovery time in exchange for a smaller or partially provisioned standby.
A worked example
Two regions serving an 80,000-request-per-second peak
Assume a service peaks at 80,000 requests per second, split evenly between two active regions. If each region supports only 50,000 requests per second, losing one leaves a 30,000-request-per-second shortfall. Active-active routing alone does not solve that failure: reserve more capacity, shed optional traffic, or accept degradation while scaling. With active-passive, a standby able to serve the full 80,000 still needs a tested promotion and routing path. If both designs use asynchronous database replication, neither guarantees zero lost acknowledged writes. The interview decision turns on permitted recovery time, data-loss tolerance, and which requests must remain available.
In the interview
- Start with the failure scope: process, availability zone, or entire region. Then name which tier is active-active or active-passive rather than applying one label to the whole system.
- State the recovery time objective, or RTO, and recovery point objective, or RPO. Explain the steps that consume recovery time and whether acknowledged writes can be lost.
- Describe a network partition, not only a clean crash. Expect questions about who may accept writes, how authority is established, and how a stale primary is fenced off.
- Calculate surviving capacity at peak traffic. Include database throughput, connection limits, cache warming, and downstream dependencies, not just API server count.
- Walk through failback and client retries. Explain how you reconcile divergent state, preserve idempotency, and avoid switching traffic to a replica that is still behind.
Common mistakes
- Equating active-active API servers with a multi-writer database, or assuming every dependency is region-independent.
- Promising zero downtime or zero data loss from the topology alone, without specifying routing, replication, and acknowledgment rules.
- Treating a timeout as proof that the old primary is dead and promoting a replacement without fencing or quorum-based authority.
- Sizing each active region for only its normal traffic share, or assuming a cold standby can instantly absorb peak load.
Where it comes up
Interview questions where choosing between Active-active and Active-passive comes up.
- Design a distributed key-value storeRegional serving and write ownership determine partition availability, replication behavior, and convergence after recovery.
- Design a payment systemChoosing write authority and safe failover is essential to preserving ledger invariants and handling retries without duplicate charges.
- Design Netflix's concurrent screen limitIndependent regional admission can exceed an account-wide limit unless slot ownership or coordination survives failures safely.
- Design a distributed message log like KafkaReplicated partition leaders require explicit acknowledgment, promotion, and fencing rules to preserve durable ordered writes.
- Design a control plane for a distributed databaseAutomated database failover must establish a single authority, fence stale primaries, and verify replica readiness.
Questions people ask
Is active-active better than active-passive?
Not universally. Active-active can improve geographic serving and reduce dependence on standby promotion, but it adds routing and coordination work. Active-passive is often easier to reason about when one write authority is valuable and a failover interval is acceptable.
Does active-active require a multi-master database?
No. Multiple active application regions can use a single database leader, leaders partitioned by tenant, or a globally coordinated database. Explain the resulting remote-write latency and what happens when a region cannot reach the write authority.
Can active-passive provide zero data loss?
It can target zero loss of acknowledged writes within a defined failure model by acknowledging only after the required durable replication. Safe promotion must select an eligible replica and prevent the old primary from continuing to write. This does not imply zero downtime, and losing the required replicas can still make writes unavailable.