Raft: consensus designed to be understood

Paxos (lesson 7) is provably correct but notoriously hard to map onto a real implementation's edge cases. Raft's 2014 paper explicitly names understandability as a primary design goal, on equal footing with correctness — the authors' explicit bet was that an algorithm engineers can actually reason about correctly is more valuable in practice than one that's marginally more elegant on paper but routinely implemented wrong.

Where Paxos treats every round somewhat symmetrically, Raft is built around a strong leader: at any time, exactly one node is the leader, and all changes flow through it — directly reusing the leader-based replication model from lesson 4, but with Raft providing the missing piece: how the leader itself is safely elected and replaced.

Every node starts as a follower. If a follower doesn't hear from a leader within a randomized timeout, it becomes a candidate and requests votes from other nodes. Whichever candidate gets a majority becomes the new leader for that term (a monotonically increasing counter identifying each leadership period, playing a similar role to Paxos's proposal numbers). The randomized timeout is a deliberately simple trick to avoid every follower becoming a candidate at exactly the same moment and splitting the vote repeatedly.

Once elected, the leader accepts client requests and appends them to its own log, then replicates each entry to followers. An entry is considered committed — safely part of the permanent record — once a majority of nodes have it in their log, at which point it's safe to apply and safe to tell the client "success." This directly extends lesson 5's replication timing discussion: Raft's commit rule is essentially synchronous replication to a majority, formalized with the same safety guarantee Paxos provides (a majority overlap prevents two different, conflicting histories from both being considered committed).

If a leader crashes, followers stop hearing heartbeats, their election timeouts fire, and a new leader election happens automatically — Raft's explicit design directly solves the "who's the new leader, safely" problem that lesson 6 identified as its own consensus problem underneath ordinary leader-based replication. Because leader election and log replication share Raft's term/majority machinery, a new leader is guaranteed to already have every previously-committed log entry, so no committed write is ever lost in the handoff.

etcd (the coordination store behind Kubernetes), Consul, and CockroachDB all use Raft, largely because its relative simplicity made it practical for teams to implement, test, and actually trust in production — a direct validation of the "understandability as a design goal" bet, and a large part of why Raft, not Paxos, is the consensus algorithm most engineers will actually encounter by name in real infrastructure.