Availability patterns and failover

System redundancy and failover

To survive hardware failure, network disconnection, or data center maintenance without downtime, systems deploy redundant hardware paired with automated failover mechanisms.

Active-passive failover (master-standby)

In an active-passive configuration (also called master-slave failover), only the active server handles traffic:

• Heartbeats: The active and passive servers exchange heartbeats. If the heartbeat is interrupted, the passive server takes over the active server's IP address and resumes service.
• Hot or cold standby: How long the outage lasts depends on whether the passive server is already running ("hot" standby) or must start up first ("cold" standby).
• Capacity implication: Usable capacity is that of the single active node ($1\times C$). The standby is insurance.
• Risk of failover: Data can be lost if the active server fails before newly written data has been replicated to the passive one.

Active-active failover (load-shared)

In an active-active configuration (also called master-master failover), both servers handle traffic and share the load:

• Full capacity utilization: Total system capacity equals $N \times C$.
• Finding the servers: If the servers are public-facing, DNS must know the public IPs of both; if they are internal, the application logic must know about both.
• Graceful degradation: If one node crashes, traffic stops going to it and the survivors absorb the load.
• Sizing requirement ($N+1$ redundancy): To avoid overloading the survivors when one node fails, the capacity of $N-1$ nodes must still exceed peak demand.

Either way, failover adds hardware and complexity.

Master-slave (primary-replica) vs master-master replication

• Master-slave: The master serves reads and writes and replicates writes to one or more slaves, which serve only reads. If the master goes offline, the system can keep running read-only until a slave is promoted or a new master is provisioned; promotion needs extra logic.
• Master-master: Both masters serve reads and writes and coordinate on writes, so the system keeps accepting writes if one fails. You need a load balancer or application logic to decide where to write, and most master-master systems are either loosely consistent (violating ACID) or have higher write latency from synchronization. Conflicts become more likely as you add write nodes and as latency grows. Chapter 4 covers replication in depth.