What consensus actually requires

Consensus means getting multiple nodes to agree on a single value, even when some nodes might crash, messages might be delayed or dropped, and no node has a complete, instant view of what every other node is doing. A correct consensus protocol must guarantee two properties simultaneously:

Lesson 4 mentioned that leader-based replication needs a new leader elected if the old one dies — and that a botched election can produce two leaders at once (split-brain). Electing a leader is exactly a consensus problem: every node needs to agree on who the one leader is, with the same safety requirement (never two nodes simultaneously believing they're the leader) and the same liveness requirement (eventually, someone actually gets elected). This is precisely why real systems don't hand-roll leader election from scratch — they build on a proven consensus algorithm (lessons 7–8) instead.

A tempting first idea: "whichever value gets votes from a majority of nodes wins." The subtlety is in what happens with overlapping, sequential votes — if node crashes and message delays let two different candidate values each briefly gather a majority in different, overlapping rounds (because some nodes' votes from an earlier round get counted again, or messages arrive out of order), a naive scheme can end up with two "majority-approved" values, violating safety. Real consensus algorithms carefully sequence rounds and track enough state specifically to make this scenario provably impossible, not just unlikely.

A well-known 1985 result (named after its authors, Fischer, Lynch, and Paterson) proves that in a fully asynchronous network — one with no upper bound on message delay — no consensus algorithm can guarantee both safety and liveness in every possible scenario; there's always some unlucky sequence of delays that prevents the system from ever deciding. Real-world consensus algorithms don't contradict this — they work around it by relying on the practical assumption that networks are usually mostly well-behaved (even if not provably bounded), using timeouts and retries to make progress in practice, while still guaranteeing safety no matter what.

Understanding what consensus actually guarantees (and where the boundary of that guarantee is) is what separates confidently trusting a tool like ZooKeeper or etcd for the exact right job — coordinating who's the leader, not serving every read in a high-throughput system — from misusing it somewhere it was never designed to be strong. Lessons 7 and 8 cover the two most influential concrete algorithms that make consensus practically achievable.