Two complementary patterns support high availability: failover and replication. Failover changes which node serves traffic. Replication keeps more than one copy of data or compute state.
Failover
Active-passive
In active-passive failover, the active server serves traffic and sends heartbeats to a passive server on standby. If heartbeats stop, the passive server takes the active server's IP address and resumes service. A hot standby is already running and reduces downtime. A cold standby must start first and takes longer.
Only one node handles traffic at a time. Older systems may call this master-slave failover.
Active-active
In active-active failover, both nodes handle traffic. A DNS service, load balancer, or application routing logic knows about both nodes. If one node fails, the other absorbs its traffic. Older systems may call this master-master failover.
- Active-passive
The router sends traffic to the active node; a standby waits.
- Promote
After health failure is established, promote the standby according to the failover rules.
- Active-active
Both nodes serve traffic. Remove an unhealthy node from routing.
- Data risk
Decide how to handle stale or unreplicated writes; a routing switch does not recover them by itself.
Health detection, promotion, and unreplicated writes still need explicit policies.
How to read this model
A traffic selector beside active and reserve worker bays. The object is a teaching analogy. Inspecting a part highlights its role; it does not execute or simulate the software. Cabinet trays are records, workpieces are data, and latches are checks. Unless an explanation states a quantity, compartments and sample workpieces do not denote data counts. Part dimensions are not a quantitative scale.
Concept redrawn from Scalable system design patterns.
Failover adds hardware and operational complexity. If the active node fails before it replicates a new write, the system may lose that write. Test promotion, stale state, and the return of the recovered node.
Replication
Replication keeps multiple copies available. Database replication covers master-replica and multi-master designs, including replication lag and conflict resolution.
Availability in numbers
Availability is usually expressed as uptime percentage. A service with 99.99% uptime has "four nines". The remaining percentage is the allowed downtime for the stated measurement period.
| Availability | Per year | Per month | Per week | Per day |
|---|---|---|---|---|
| 99.9% | 8h 45m 57s | 43m 49.7s | 10m 4.8s | 1m 26.4s |
| 99.99% | 52m 35.7s | 4m 23s | 1m 5s | 8.6s |
An availability target is a budget for failed time, not a guarantee that failures become impossible. Define whether the measurement includes planned maintenance, dependency failures, and degraded responses.
Components in sequence and in parallel
If a request needs both Foo and Bar, their availabilities multiply:
Availability(total) = Availability(Foo) * Availability(Bar)
Two components at 99.9% availability provide 99.8% when they are both required.
If either of two parallel components can serve the request, the combined availability is:
Availability(total) = 1 - (1 - Availability(Foo)) * (1 - Availability(Bar))
Two independent components at 99.9% availability provide 99.9999% in parallel. Independence is an assumption. A shared network, deployment, or operator can still fail both nodes.