We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
2 system design questions lean on this idea. Each walks through the full answer.
System Design Masterclass · Reliability Resilience
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Reliability Resilience
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Active-passive is the oldest and most widely deployed failover pattern in production systems. One node serves all traffic. A second node sits idle, receiving replicated data, ready to take over if the primary dies. Half of your infrastructure sits unused most of the time, and that is the point.
The appeal is simplicity. There is never a question about which node owns the data. There is no conflict resolution, no split brain risk, no cross-region write merging. The primary writes, the standby replicates, and the promotion path is a single, well-tested operation. PostgreSQL with Patroni, MySQL with Orchestrator, and Aurora with automated failover all implement this pattern. AWS RDS Multi-AZ is active-passive under the hood.
The cost is that idle standby. In a two-node setup, 50% of your database capacity sits unused during normal operations. In exchange, you get a failover path that teams can understand, test, and trust. For stateful systems like relational databases where two concurrent writers would cause data corruption, active-passive is often the only safe choice. How the primary and standby are wired together underneath, from streaming and slots to synchronous commit and fencing, is covered in my lesson on active-passive configuration.
| Phase | What Happens | Duration |
|---|---|---|
| Steady state | Primary serves all reads and writes. Standby receives replicated data continuously. | Indefinite |
| Failure detection | Health checks or heartbeats detect the primary is unresponsive. | 10 to 90 seconds depending on check interval and failure threshold |
| Promotion | The standby is promoted to primary. Pending WAL or binlog entries are replayed. | 10 to 60 seconds for managed services, 1 to 5 minutes for self-managed |
| Traffic shift | DNS, , or virtual IP redirects clients to the new primary. | Seconds for VIP/LB, minutes for depending on TTL |
| Verification | SLO probes confirm the new primary is serving correctly. | 1 to 5 minutes |
The total failover time is the sum of all five phases. A well-tuned Aurora Multi-AZ failover completes in about 30 seconds. A self-managed PostgreSQL cluster with Patroni typically completes in 10 to 30 seconds. MySQL with Orchestrator is similar. The numbers are achievable, but only if the promotion path has been tested within the last quarter.