Compare active-active and active-passive architectures across traffic, state, capacity, failover, consistency, split-brain risk, cost, and operations.
Active-active and active-passive describe how multiple sites or failure domains participate in normal service. They do not, by themselves, specify the consistency model, recovery time, or degree of automation.
The important questions are which operations each location can perform, where authoritative state lives, how traffic moves, and what happens during a network partition.
| Dimension | Active-active | Active-passive |
|---|---|---|
| Normal traffic | distributed across several locations | directed to the primary location |
| Standby utilization | capacity is already serving | capacity may be absent, stopped, scaled down, or idle |
| Failover work | isolate the failed location and rebalance | promote, scale, validate, and redirect to the standby |
| Capacity efficiency | production uses capacity in several locations | standby cost depends on how much is pre-provisioned |
| State complexity | concurrent writes, conflict, partitioning, or ownership must be managed | promotion and replication lag must be managed |
| Typical RTO potential | low if surviving locations have capacity and state | ranges from hours to minutes depending on readiness |
| Main operational risk | correlated failure, split brain, overload, hidden shared state | stale standby, failed promotion, missing capacity, configuration drift |
Neither pattern is automatically better. Active-active is justified when low interruption, geographic latency, or continuous use of multiple sites outweighs its state and operational complexity. Active-passive is often easier to reason about and can meet many recovery targets at lower cost.
Requests can run in any location because durable state is external or partitioned safely. This is the easiest form, but sessions, caches, rate limits, identity, and queues can still introduce hidden state.
Several locations serve reads, while one location accepts authoritative writes. This can improve read latency and availability without requiring conflict resolution for concurrent writes. A primary failure still requires writer promotion.
Each location owns writes for a defined tenant, key range, or geographic partition. Other locations may serve replicas. Failover transfers ownership. This reduces concurrent-write conflicts but requires routing and rebalancing logic.
Several locations accept writes to the same logical data. The system needs a defined consistency and conflict model: synchronous agreement, consensus, last-writer rules, mergeable data types, application reconciliation, or another deterministic policy.
Calling a design active-active without naming its write model hides the hardest part.
| Standby state | Normal condition | Failover requirement |
|---|---|---|
| Backup and rebuild | data copies and definitions exist; service stack is not running | provision, restore, configure, validate, route |
| Pilot light | core state or minimal foundation is running | deploy or start application tiers, scale, validate, route |
| Warm standby | complete stack runs at reduced capacity | scale, promote state if needed, validate, route |
| Hot standby | complete production-capable stack is ready but not normally serving | promote or redirect traffic and verify state |
Teams use these labels differently. Document the actual running capacity, data state, deployment state, promotion steps, and tested timings rather than relying on the label.
Before distributing traffic, answer:
If the answers are unclear, start with a simpler ownership model.
Split brain occurs when isolated parts of a system both believe they are authoritative. It can lead to conflicting writes, duplicate work, over-allocation, or irreversible integrity loss.
Controls include:
Automatic failover should not trade a short outage for corrupted state. For some systems, refusing writes during uncertainty is the safer availability decision.
Failover time can include:
A low DNS time-to-live can reduce one delay, but it does not force clients to discard cached answers, close established connections, or retry correctly.
An active-active system running each of two locations at 70 percent utilization cannot lose one location and carry 140 percent load on the survivor. Resilience requires enough headroom, load shedding, priority, rapid scaling, or more than two locations.
Similarly, a warm standby may have the right infrastructure but lack quota, licenses, data throughput, or downstream capacity to scale under incident pressure.
| Requirement | Strong starting pattern |
|---|---|
| Hours of recovery time are acceptable and cost dominates | backup and rebuild |
| Data must stay replicated, but application capacity may start later | pilot light |
| Recovery in minutes with predictable operations | warm or hot standby |
| Low global read latency, one authoritative writer | read-active with write-primary |
| Continuous service across a local failure domain | active-active stateless tiers with resilient state |
| Multi-region writes with very low interruption | multi-writer only if consistency and conflict behavior are explicit |
| Error | Better rule |
|---|---|
| “Active-active guarantees zero downtime.” | Detection, capacity, traffic, clients, state, and shared dependencies still matter. |
| “Both locations are active, so both should accept writes.” | Read activity and write authority are separate design choices. |
| “Warm standby means a specific RTO.” | Measure the actual promotion, scaling, validation, and routing workflow. |
| “DNS failover moves every client immediately.” | Account for caches, resolvers, connections, and retry behavior. |
| “The surviving site can scale when needed.” | Verify quota, capacity, control-plane access, and scaling time during exercises. |
Continue with Recovery Strategy Patterns to choose the complete recovery operating model.