Raft on a whiteboard
Leader election, log replication and log matching, one step at a time. Press Next to step through it.
Turn your phone sideways for a bigger board.
Every node starts as a follower
This cluster has five nodes, and each one starts as a follower. A follower is passive: it only answers messages from leaders and candidates.
Read the whole walkthrough as text
Every node starts as a follower
This cluster has five nodes, and each one starts as a follower. A follower is passive: it only answers messages from leaders and candidates.
Open: the “Terms and Roles” section
An election timeout fires
S1 hears no heartbeat before its election timeout runs out. It becomes a candidate, moves to term 2 and votes for itself.
Open: the “Leader Election” section
RequestVote to every peer
The candidate asks every other node for its vote in term 2.
Open: the “Leader Election” section
A majority of votes wins
A peer votes yes if it hasn't voted this term and the candidate's log is at least as up-to-date as its own. S1 collects 3 of 5 votes, its own included. That is a majority.
Open: the “Leader Election” section
The leader sends heartbeats
S1 becomes leader and starts sending heartbeats right away: AppendEntries messages with no entries. As long as they keep arriving, no follower starts an election.
Open: the “Leader Election” section
When two candidates tie
If two nodes start elections at the same moment, the votes can split so neither reaches a majority. Both time out and retry with a new term. Randomized timeouts, typically 150-300 ms, make another tie unlikely.
Open: the “Leader Election” section
A client write reaches the leader
A client sends x=5 to the leader. The leader appends it to its own log, but the entry isn't committed yet.
Open: the “Log Replication” section
AppendEntries goes out in parallel
The leader sends the entry to every follower at once. S2, S4 and S5 write it to their logs. S3 is unreachable, and that's fine: the leader doesn't need everyone.
Open: the “Log Replication” section
Committed once a majority has it
The entry is on three of five logs, so the leader marks it committed, applies it to its state machine and replies to the client. Followers learn the commit index on the next heartbeat and apply it too.
Open: the “Log Replication” section
A follower with a diverged log
Suppose S3 comes back holding a stale entry from an earlier term. Every AppendEntries carries the index and term of the entry just before the new one. S3's doesn't match, so S3 rejects the append.
Open: the “Safety: Log Matching” section
The leader repairs the follower
The leader backs up and resends from an earlier point until it finds a common prefix, then overwrites the diverged entries. If two logs share an entry's index and term, everything before it is now identical too.
Open: the “Safety: Log Matching” section
If the leader crashes
Heartbeats stop, an election timeout fires on a follower, and a new election starts in term 3. Nodes refuse to vote for a candidate with a less complete log, so the winner already has every committed entry. There is no repair phase.
Open: the “Leader Failure” section
Recap
Raft splits consensus into leader election, log replication and safety. Everything goes through one leader, a majority decides, and terms expose stale leaders.
Open: the “Where It Runs” section