Replication is the foundation of fault tolerance, yet most replication protocols carry substantial complexity. Consensus algorithms like Paxos and Raft require multiple rounds of communication, handle leader election as an intricate subproblem, and demand careful reasoning about quorum intersection. For many systems, this complexity is necessary. But not always.

Primary-backup replication represents the minimal correct solution to the replication problem under specific assumptions. A single primary processes all requests and forwards updates to backups before acknowledging clients. When the primary fails, a backup takes over. The protocol's simplicity is not a limitation—it's a theorem about what's achievable given certain environmental guarantees.

Understanding primary-backup formally reveals something important: the complexity of other replication protocols isn't arbitrary. It exists precisely to weaken the assumptions that primary-backup requires. When you can satisfy those assumptions—perfect failure detection, reliable communication channels, external coordination—primary-backup provides linearizability with minimal mechanism. When you cannot, you need consensus. The choice between them isn't about preference; it's about what your environment can actually guarantee.

The formal specification of primary-backup begins with defining the system model. We have a set of processes P = {p₁, p₂, ..., pₙ} where one process is designated primary and others are backups. Clients submit operations to the primary, which assigns a total order to all operations via sequence numbers.

In synchronous primary-backup, the primary receives operation o, assigns sequence number sn, sends (o, sn) to all backups, waits for acknowledgments from all backups, applies o locally, then responds to the client. The key invariant is: no operation is visible to clients until all non-faulty processes have received it.

We can prove linearizability by construction. Define the linearization point of operation o as the moment the primary applies it. Since the primary totally orders operations and all backups apply them in the same order, every process maintains an identical state sequence. Any read from the primary reflects exactly the operations linearized before it.

Asynchronous primary-backup relaxes the requirement to wait for all backups. The primary acknowledges after applying locally, then asynchronously propagates to backups. This provides session consistency but not linearizability—a client might read from a backup that hasn't received recent writes.

The formal distinction matters: synchronous primary-backup satisfies the specification ∀ operations o₁, o₂: if o₁ →_client o₂ then o₁ →_{linearization} o₂. Asynchronous primary-backup only guarantees this for operations from the same client. The weaker guarantee enables dramatically lower latency—the primary doesn't wait for network round trips to backups.

Takeaway

Synchronous primary-backup achieves linearizability by making all state changes globally visible before acknowledgment. Asynchronous variants trade consistency for latency—the right choice depends on which property your application can sacrifice.

Failover is where primary-backup's simplicity reveals its hidden complexity. The protocol requires a perfect failure detector—a mechanism that eventually suspects crashed processes and never suspects correct ones. This is impossible in asynchronous systems with unreliable failure detection, which is precisely why consensus protocols exist.

Consider the failure modes formally. If the primary crashes after sending updates to some backups but before others, we have partial propagation. Safe failover requires selecting a backup with the most recent state. In synchronous mode, this is the backup with the highest received sequence number. But determining this requires communication among backups—which starts resembling consensus.

The split-brain problem emerges when failure detection is imperfect. If a backup incorrectly believes the primary has failed and promotes itself, we have two primaries accepting writes. Their states diverge, violating our consistency guarantees. Preventing split-brain requires either perfect failure detection or a fencing mechanism that guarantees the old primary cannot process operations.

Fencing typically relies on an external coordination service. The new primary obtains a lease or epoch number that invalidates all previous primary authority. Clients include the epoch in requests; the old primary rejects requests with new epochs. This works, but note what happened: we outsourced the hard consensus problem to an external service.

The formal requirement for safe failover is: at most one process acts as primary for any given epoch, and epochs are totally ordered. Implementing this without external coordination requires solving consensus. With external coordination (ZooKeeper, etcd), primary-backup delegates consensus rather than avoiding it.

Takeaway

Primary-backup's simplicity is partially illusory—the hard problems of failure detection and primary election are typically delegated to external systems rather than eliminated. Understanding this delegation clarifies when the approach is genuinely simpler versus when it merely relocates complexity.

Consensus-based replication (Paxos, Raft, Viewstamped Replication) solves a strictly harder problem. These protocols provide linearizability without assuming perfect failure detection or external coordination. The additional mechanism—quorums, leader election subprotocols, log reconciliation—exists to handle exactly the scenarios where primary-backup breaks.

The FLP impossibility result proves that no deterministic algorithm can achieve consensus in an asynchronous system with even one faulty process. Practical consensus protocols circumvent this by using timeouts (weakening asynchrony) or randomization. Primary-backup circumvents it by assuming perfect failure detection—a stronger assumption that may be satisfied in controlled environments.

When is primary-backup appropriate? First, when failure detection is genuinely reliable. In a tightly controlled datacenter with redundant networking and hardware monitoring, failure detection approaches perfection. Second, when external coordination already exists. If your system depends on ZooKeeper anyway, using it for primary election adds minimal complexity.

Third, when the replication factor is exactly two. Primary-backup with one backup has minimal coordination overhead. Consensus protocols optimize for f failures among 2f+1 nodes; at small scales, this optimization matters less. Fourth, when latency matters more than availability during partitions. Primary-backup can provide single-round-trip writes; consensus requires additional rounds.

The decision framework is: if you can externalize the consensus problem and your environment supports reliable failure detection, primary-backup is provably correct with less mechanism. If you cannot make these assumptions, consensus protocols earn their complexity. The mathematical relationship is precise—primary-backup plus perfect failure detection equals the power of consensus.

Takeaway

Primary-backup doesn't avoid the fundamental problems that consensus solves—it assumes them away. In environments where those assumptions hold, the simplicity is genuine. In environments where they don't, the simplicity is an illusion that will eventually manifest as correctness bugs.

Primary-backup replication deserves formal study precisely because it establishes a baseline of minimal mechanism. Every additional component in consensus protocols can be traced to weakening primary-backup's assumptions about failure detection or coordination.

The practical lesson is about honest accounting. Primary-backup systems using external coordination services haven't eliminated consensus—they've imported it. This is often the right engineering choice, but understanding the trade-off prevents confusion when the external service becomes a reliability bottleneck.

Choose primary-backup when its assumptions match your environment. Choose consensus when they don't. The mathematics admits no middle ground—either you have perfect failure detection (possibly via external systems) or you need the full apparatus of distributed consensus.