Your database is down. Users are hitting errors, revenue is bleeding, and the on-call engineer is staring at a promotion sequence that's taking too long. The architecture decision you made six months ago is now the difference between a brief blip and a full-blown incident.Active-active and active-passive are two fundamentally different approaches to keeping your database available when things go wrong. This guide covers how each architecture works, the key tradeoffs, and how Redis approaches active-active.What "high availability" really means for your databaseHigh availability means a database keeps serving requests even when individual components fail. It comes from how you engineer the system: redundancy, alternate equipment, and deliberate failover design. Contingency planning ties these pieces together into a plan for keeping systems resilient and recovering quickly when disruptions hit.The industry measures availability in "nines," and each one costs more than the last.Availability levelMax downtime per yearMax downtime per month99% (two nines)~87.6 hours~7.2 hours99.9% (three nines)~8.76 hours~43.8 minutes99.99% (four nines)~52.6 minutes~4.4 minutes99.999% (five nines)~5.26 minutes~26 secondsHere's the thing most teams overlook: diminishing returns. Going from 99.99% to 99.999% is exponentially more expensive to engineer than going from 99% to 99.9%. There's no universally correct tier, only the tier that makes economic sense for your workload.Two metrics define what recovery looks like for your system. Recovery Time Objective (RTO) is maximum downtime before it causes unacceptable business impact. Recovery Point Objective (RPO) is the recovery point after an outage, or how much data loss you can handle.Both RTO and RPO are shaped by your replication architecture. Replication tradeoffs connect these metrics to a core tradeoff: synchronous replication can help ensure near-zero RPO but adds write latency, while asynchronous replication reduces latency but creates an RPO gap equal to the replication lag at the moment of failure. This is what makes the active-active vs active-passive decision non-trivial.One way to push RTO toward zero is to remove the promotion step entirely. Active-active is a database architecture where multiple nodes run at the same time, each accepting reads and writes. There's no single primary, so if one node goes down, the others keep handling traffic without waiting for a standby to take over. It's sometimes called multi-master or bi-directional replication.The payoff shows up during failures. Every node is already live, so traffic shifts to a healthy node without any promotion step. That's why active-active can reach much lower RTO than active-passive setups in well-designed deployments.Handling concurrent writesThe one thing active-active has to get right is concurrent writes. When multiple nodes accept writes at the same time, two nodes can modify the same record simultaneously, and reverse-order processing can leave the nodes inconsistent if there's no resolution strategy in place.Two well-understood strategies handle this. Last Writer Wins (LWW) is the simplest: the operation with the most recent timestamp survives. It works for some use cases, but not when both updates carry meaningful information. Conflict-free Replicated Data Types (CRDTs) are more durable: they make operations commutative by construction, so the same set of updates converges to the same final state regardless of application order, with no conflicts to resolve at the application layer.Get started with Redis for faster appsReduce latency and handle data in real time.