Consensus

Consensus is not "making the cluster consistent". It is a much narrower thing: getting a set of nodes to agree on one value, once, in a way that survives some of them failing — and every other agreement problem you meet is this one wearing a costume.

Q · What problem does consensus actually solve, and what does it leave untouched?

Every guarantee in the previous lesson is conditional. Consensus needs a reachable majority, a network that eventually behaves, and a failure model that excludes lying nodes. Take any one away and the protocol does not degrade gracefully — it stops, or it stops being correct.

Q · What does a consensus protocol assume, and what happens when the assumption is false?

Many designs need exactly one node to act — one writer, one scheduler, one owner of a shard. Electing that node is easy. The hard part is that the node it elected cannot tell the difference between "I am still the leader" and "I was replaced eleven seconds ago and nobody could reach me to say so".

Q · How does a cluster choose exactly one node to act — and how does that node know it still may?

You cannot stop an old leader from believing it leads. What you can do is number leadership generations and have everyone reject anything stamped with an old number. A monotonically increasing counter is the whole mechanism — and it is why split-brain is survivable rather than catastrophic.

Q · If a deposed leader keeps acting, why does the system not corrupt itself?

A partition does not produce confusion. It produces two internally consistent, entirely reasonable worlds, each of which believes it is the whole world. Neither node is malfunctioning. The danger is not the belief — it is what the system lets a believer do.

Q · A partition splits my cluster and both halves think they are in charge. What actually goes wrong, and what stops it?

Every timeout-based scheme leaves a window where an old holder still believes it holds authority. You cannot close the window. A fencing token makes the window harmless: the resource itself remembers the highest token it has accepted and refuses anything lower, so a stale actor’s writes bounce off.

Q · How do I stop a node that lost its lock — but does not know it — from corrupting the resource it was protecting?

Raft was designed to be understandable, and its elections are the reason. Three states, one timeout, one rule about who may vote, and one rule about who may win — from which the guarantee "a new leader already holds every committed entry" falls out without any case analysis.

Q · How does Raft choose a leader, and why can the winner never be missing committed data?

The leader writing an entry to its own log means nothing. An entry is committed when it is replicated to a majority — and until then it is a proposal that a future leader is free to delete. Understanding that one distinction explains every log divergence you will ever debug.

Q · When is an entry actually committed, and what happens to entries a deposed leader wrote but never committed?

Paxos came first and proved the problem was solvable; Raft came later and proved it could be explainable. They reach the same guarantees by different decompositions. Knowing the shape of the family — and the one property they all share — matters far more than being able to derive any of them.

Q · How do Paxos, Multi-Paxos, Zab and Viewstamped Replication differ from Raft — and does the difference change anything I do?

Consensus is the right tool for a small number of facts and the wrong tool for almost everything else. The failure mode is not choosing it when you should not — it is putting it in the path of every business operation, and discovering that your throughput ceiling and your availability floor are now the same number.

Q · This decision feels like it needs agreement. Does it actually need consensus?