Paxos is famously, almost proudly, hard to understand. Leslie Lamport's own retrospective on it admits the original paper needed a follow-up just to explain the first one. For years, this made consensus, getting a cluster of machines to agree on a sequence of values even when some of them crash, something only a handful of distributed systems experts felt comfortable implementing correctly.
Diego Ongaro and John Ousterhout set out to fix that, not by inventing a fundamentally new algorithm, but by explicitly optimizing for understandability as a design goal in its own right. The result, Raft, decomposes consensus into three separate, much smaller problems: leader election, log replication, and safety. It is now the algorithm behind etcd (which powers Kubernetes), Consul, and CockroachDB.
Raft achieves the same guarantees as Paxos by electing a single leader that owns all writes, then replicating a log of commands to followers. Understandability came from splitting the problem into leader election, log replication, and safety, and solving each independently.
Three states, one election timer
Every server in a Raft cluster is in exactly one of three states at any time: Follower, Candidate, or Leader. A healthy cluster has exactly one leader and every other server is a follower, passively accepting log entries and heartbeats from it.
The core state machine every Raft server runs. Followers become candidates when they stop hearing from a leader; candidates become leaders by winning a majority vote.
Followers expect to hear from the leader regularly, in the form of heartbeat AppendEntries RPCs. Each follower keeps a randomized election timeout (typically 150 to 300 milliseconds in the paper), and resets it every time it hears from the current leader. If the timeout fires before a heartbeat arrives, the follower assumes the leader is gone, and promotes itself to candidate.
A candidate increments a monotonically increasing term number (Raft's logical clock), votes for itself, and requests votes from every other server via RequestVote RPCs. Each server votes for at most one candidate per term, first-come-first-served. Collect votes from a majority, and the candidate becomes leader for that term.
The randomized timeout is doing more work than it looks like. If every follower timed out at exactly the same moment, they would all become candidates simultaneously, split the vote, and the cluster could churn through repeated failed elections. Randomization makes one follower almost always time out first, giving it a clean shot at a majority before anyone else even notices the leader is gone.
Split votes still happen occasionally, especially in a small cluster where two timeouts land close together by chance. Raft does not treat this as an error, a candidate that fails to win simply lets its own election timer expire again, picks a fresh random timeout, and starts a new term. Because every retry re-rolls the randomness independently, the odds of colliding twice in a row are low.
A and B fire their election timeouts close together and split the vote between them. Their next timeouts are re-randomized independently, so a repeat collision is unlikely.
Log replication: the leader does all the writing
Once elected, the leader is the only server that accepts client requests. Each request becomes a log entry, tagged with the current term, that the leader appends to its own log and then replicates to every follower in parallel via AppendEntries. When a majority of servers (including the leader itself) have durably stored the entry, the leader considers it committed and applies it to its own state machine, only then responding to the client.
Log entries are only committed once they exist on a majority of servers. A lagging follower does not block progress.
Followers do not need to individually agree on when something is committed. The next heartbeat from the leader carries a leaderCommit index, and every follower simply applies entries up to that index to its own state machine. This keeps the protocol simple: only the leader ever decides what is committed, and it broadcasts that decision rather than negotiating it.
The log matching property
Raft leans on one clean invariant to keep replicated logs consistent: if two logs contain an entry with the same index and the same term, then the logs are identical in every entry up to and including that index. This holds because a leader creates at most one entry per log index per term, and never reorders entries. AppendEntries RPCs include the index and term of the entry immediately preceding the new ones, and a follower rejects the RPC unless its own log already matches at that point, so any inconsistency is caught immediately rather than silently spreading.
Safety: never electing a leader with a stale log
There is one dangerous scenario the state machine and replication rules alone do not prevent: what if a server that missed some committed entries wins an election anyway? Raft closes this gap with an election restriction. A voter refuses its vote to any candidate whose log is not at least as up to date as its own, comparing the term of each server's last log entry first, and the length of the log as a tie-breaker.
Because becoming leader requires a majority of votes, and a committed entry must already exist on a majority of servers, any majority large enough to elect a new leader is guaranteed to overlap with any majority that committed a previous entry, in at least one server. That overlapping server will refuse to vote for a candidate whose log is behind it, so a committed entry can never be silently lost by a future leader.
This is the subtle part that makes consensus algorithms hard to implement correctly, and exactly why Raft spends so much of the paper on a formal proof of this property. Get the election restriction wrong, even slightly, and you can lose committed data during a leader change without any obvious symptom until much later.
Membership changes and log compaction
Two practical problems remain for any real deployment. First, cluster membership sometimes needs to change (adding or removing a server). Switching directly from an old configuration to a new one is unsafe, since different servers might see the switch at different times and two disjoint majorities could each elect their own leader. Raft's original solution is joint consensus: a transitional configuration that requires majorities from both the old and new configurations before it takes effect, guaranteeing there is never a moment where two independent majorities can both make progress.
Second, an ever-growing log is not practical to keep or replay forever. Raft servers periodically write a snapshot of their full state machine to stable storage and discard log entries up to the snapshotted index. A follower that has fallen far behind can be caught up with a single InstallSnapshot RPC instead of replaying thousands of individual log entries.
Why this paper still matters
Raft is now the default answer whenever a system needs a small group of servers to agree on something reliably: etcd uses it to store all of Kubernetes' cluster state, Consul uses it for service discovery, and CockroachDB and TiKV use it per data range to replicate ranges of a distributed SQL database. It has largely displaced Paxos in new systems, not because it is more powerful, the two are provably equivalent in what they can guarantee, but because teams can actually reason about it, test it, and debug it in production.
The paper itself is also worth reading as a case study in technical communication: it deliberately includes extra figures, a complete formal proof in the appendix, and even reports on a user study showing students understood Raft better than Paxos after equivalent instruction. Understandability was not a footnote, it was the paper's actual contribution.
Key takeaways: one leader owns all writes and replicates a log to followers, entries commit once stored on a majority, randomized election timeouts avoid split votes, and the election restriction guarantees a new leader always has every previously committed entry.
