Raft: How Five Machines Agree on One Truth Without a Boss

The problem consensus actually solves

Any system that replicates data across several machines for fault tolerance faces the same question: when the machines disagree — because one crashed mid-write, or a network partition split them apart — which version is correct? Consensus is the guarantee that a cluster of nodes agrees on a single sequence of values (typically a log of commands) even when some nodes crash or messages are delayed, as long as a majority of nodes are alive and can talk to each other.

Raft, published by Diego Ongaro and John Ousterhout in 2014, was designed explicitly to be an understandable alternative to Paxos, which is provably correct but notoriously resistant to intuition. Raft decomposes consensus into three separable sub-problems — leader election, log replication, and safety — each of which can be reasoned about mostly on its own.

Every node is always in exactly one of three states

Follower   → passive; responds to RPCs from a leader or candidate; default state
Candidate  → actively campaigning for votes after an election timeout
Leader     → the one node currently accepting client writes and replicating them

Followers who hear nothing before their election timeout expires become Candidates.
Exactly one Candidate normally wins and becomes Leader for that term.

Time is divided into terms, monotonically increasing integers that act as a logical clock. At most one leader can be elected per term — this is enforced simply because a node only ever casts one vote per term, first-come-first-served, so a candidate needs a strict majority of votes in that term to win, and two candidates cannot both win a majority of the same set of voters.

Leader election: randomized timeouts as the tie-breaker

A follower that has not heard a heartbeat from the current leader within its election timeout assumes the leader is gone, increments the term, votes for itself, and requests votes from every other node. The one deliberately clever detail is that the timeout is not fixed — it is chosen randomly from a range (the paper uses 150-300ms) independently by each node:

electionTimeout = random(150ms, 300ms)   // re-rolled every time it resets

// why randomness matters:
// if every follower used the SAME fixed timeout, all of them would time out
// simultaneously, all become candidates at once, split the vote evenly,
// and repeat forever with no leader ever winning a majority.
// randomizing means one node's timer almost always fires first, it becomes
// a candidate before the others notice, and usually wins outright.

If a split vote does happen anyway (two candidates time out close together and split the followers), the term simply expires without a winner and every node re-rolls a fresh random timeout for the next term — split votes are rare in practice and self-resolve within one or two extra rounds, not a source of prolonged unavailability.

Log replication: majority quorum, not unanimous agreement

Once elected, the leader is the only node that accepts client commands. It appends each command to its own log, then sends it to every follower in parallel via AppendEntries RPCs. Crucially, the leader considers an entry committed — safe, durable, guaranteed to survive any future leader change — as soon as a majority of nodes (including itself) have stored it, not all of them:

cluster of 5 nodes → needs 3 acknowledgments to commit an entry (majority = 3 of 5)
cluster of 3 nodes → needs 2 acknowledgments to commit an entry (majority = 2 of 3)

// this is why Raft clusters use ODD sizes: 3, 5, 7 — an even-sized cluster
// buys no extra fault tolerance over the next odd size down, because a
// majority requires the same number of survivors either way

This majority quorum is the mechanism that lets the cluster keep making progress even if a minority of nodes are down or unreachable — a 5-node cluster tolerates 2 simultaneous failures and keeps committing writes, because 3 nodes is still a majority. It is also why Raft clusters are sized odd: a 4-node cluster still only tolerates 1 failure (you need 3 of 4 for a majority, same as needing 2 of 3), so the 4th node buys nothing but extra network chatter.

Why a stale leader cannot silently overwrite committed data

The subtle part of the safety argument: what stops a node that was disconnected during an election, missed several committed entries, and later reconnects and somehow becomes leader from overwriting history that clients were already told was durable? Raft's answer is the election restriction — a candidate's RequestVote RPC includes the index and term of its own last log entry, and a voter refuses to grant its vote to any candidate whose log is less up-to-date than its own. Since committing an entry already required a majority to have it, and winning an election also requires a majority of votes, those two majorities must overlap in at least one node by the pigeonhole principle — so any node capable of winning an election is guaranteed to already hold every previously committed entry. A stale-log candidate simply cannot win a majority of votes in the first place.

Partitions: the minority side correctly refuses to serve writes

A network partition that splits a 5-node cluster into a group of 3 and a group of 2 is the clearest illustration of the whole design. The group of 3 still has a majority: it can elect a leader (if it does not already have one) and keep committing new entries normally. The group of 2 cannot form a majority of 5 — any node there that times out and starts an election will keep incrementing the term and requesting votes, but will never collect the 3 votes it needs, so it can never become a functioning leader and the minority side correctly stops accepting writes rather than risk two leaders disagreeing. When the partition heals, the minority side's stale or uncommitted entries are simply overwritten by AppendEntries from the majority side's leader, and the log converges to one consistent history.

This is Raft trading availability for consistency during a partition (in CAP-theorem language, it is a CP system): rather than let both sides of a split keep accepting writes and risk an unresolvable conflict, the minority side simply stops serving until it can rejoin a majority. That is a deliberate, principled choice — not a bug — and it is exactly the behaviour the live simulation on this page demonstrates when you partition or kill nodes: watch the minority side stall while the majority side keeps electing leaders and committing entries.

Frequently asked questions

Try it live

Everything above runs in your browser — open Distributed Consensus (Raft) and change the parameters while it is running. Nothing is installed, nothing is uploaded, the whole model lives in one tab.