Don't Panic — Distributed Consensus

Distributed consensus is the arrangement used when several machines must keep one durable answer while the network behaves like a courier with a vague relationship to time. It is not a vote counter bolted to a database. It is a protocol for choosing one value, or one position in a shared history, despite late messages and failed participants.

The useful picture is a replicated state machine. A client command enters a replicated log, the log settles on one order, and deterministic replicas apply that order. Consensus decides where a command goes. The application decides what the command means. This division is less glamorous than saying the cluster is clever, but it prevents several expensive misunderstandings.

The hinge is a quorum, usually a majority of voters. Any two majorities overlap, so later decisions carry knowledge of earlier ones rather than launching a rival history from the other side of a partition. A three-voter cluster needs two voters. Five needs three. Four also needs three, which is the distributed-systems version of bringing an extra chair to a meeting and discovering it cannot vote.

The surprising part is that waiting is often correct. Agreement and validity protect the history from conflicting decisions. Termination describes when progress eventually returns. A timeout is not a tiny certificate announcing that another machine has died; it is a local reason to try the next protocol step. Practical systems use timing assumptions so a stable leader and quorum can eventually work together, while keeping the safety rules intact.

Raft makes this visible with leaders, followers, candidates, terms, and log indexes. Paxos reaches the same kind of safety through numbered proposals, promises, and accepted values. Neither one turns arbitrary faulty behavior into a crash fault, nor does either make an external payment happen exactly once because a log entry committed. Those are separate contracts, which is a very useful sentence to have nearby before a design meeting.

Start with the intro for the complete model: quorums, failure and timing assumptions, reads, reconfiguration, and the boundary around transactions. Use the slides when the relationships need a diagram-sized shape. Keep the cheatsheet beside a design review, then run the exercise to watch a majority preserve one committed prefix through a partition. The reference links carry the original papers and the Raft visualization when the cheerful overview has run out of useful rope.

Don't Panic — Distributed Consensus

Relevant careers