Learning LabExplorable explanations
← All artifacts
Distributed Systems

Raft: Leader Election & Replication

Five nodes have to agree on one log, even when servers crash. Kill the leader and watch randomized timeouts elect a new one, replicate to a majority, and recover without losing a committed entry.

raftconsensusdistributed-systemsreplication
LiveInteractive · drag, toggle, run it
Distributed Systems · Consensus

Raft: Leader Election & Replication

Five nodes have to agree on a single ordered log while any of them can crash at any moment. Raft pulls this off by electing one leader on randomized timeouts, replicating its log to a majority, and re-electing the moment that leader goes dark. Kill the leader below and watch the cluster heal.

Speed
Highest term 0 · committed 0
N0term 0N1term 0N2term 0N3term 0N4term 0
Follower
Candidate
Leader
Down
What is happening

Five nodes start as followers in term 0. Each waits a randomized election timeout before assuming the leader is gone. The shortest timer fires first.

Replicated logs
Each box is a log entry labelled with the term it was created in. Solid terracotta means committed (safely stored on a majority); dashed gray means replicated but not yet committed. Press Submit command while a leader exists and watch an entry spread outward, then commit once a majority hold it.
N0
empty
N1
empty
N2
empty
N3
empty
N4
empty
The two safety rules

At most one leader per term. To win, a candidate needs votes from a strict majority (3 of 5), and each node casts at most one vote per term. Two different candidates would each need their own majority, but any two majorities of 5nodes must share at least one node, and that node only voted once. So a term can never produce two leaders. Randomized timeouts make ties rare; when a term does split with no winner, everyone just times out again and tries a higher term.

Committed entries are never lost. An entry commits only after a majority store it. A new leader is also elected by a majority, and the election rule only grants a vote to a candidate whose log is at least as up to date as the voter's. Those two majorities overlap, so any committed entry is already present in the new leader's log. Kill the leader after an entry commits and you will see the next leader keep it; kill it before commit and the half-replicated entry can vanish, which is exactly why commit waits for a majority.

Election timeouts are drawn from a seeded PRNG (per-node jitter), so the run is reproducible across reloads