Raft Consensus Lab
royhp.comRaft is leader-based consensus — the design behind etcd, Consul and CockroachDB. Exactly one node per term may act as leader; it alone accepts writes and replicates them to followers, and an entry is committed once a majority holds it. When followers stop hearing heartbeats they time out, become candidates, and start an election — the first to win a majority of votes leads the next term. Kill the leader, split the network, and watch the cluster heal itself.
Replicated logs
solid = committed (majority) · faded = uncommitted · color = termLeader election
Every follower runs a randomized election timeout (the draining arc around each node) that is reset each time a heartbeat arrives. Silence means the leader is gone: the first node to time out increments the term, votes for itself, and asks the others for votes. A node grants at most one vote per term — first come, first served — so at most one candidate can reach a majority, and randomization keeps two nodes from timing out together forever (a split vote just times out and retries).
The term number acts as a logical clock: any node that sees a higher term immediately steps down to follower. That is how a deposed leader learns its reign is over.
Log replication
Clients send writes to the leader (followers redirect — try tapping one in write mode). The leader appends the entry to its log and ships it to followers in AppendEntries messages — the same message that serves as the heartbeat. Once a majority holds the entry the leader marks it committed and tells everyone in the next heartbeat; watch entries turn solid in the log panel as that happens.
Each AppendEntries carries the index and term of the entry before the new ones. If a follower's log doesn't match at that spot it refuses, and the leader backs up one entry and retries — walking backwards until the logs agree, then overwriting everything after that point. Consistency is restored mechanically, with no special cases.
Partitions & safety
Partition the network and the leader's side may be the minority: it still accepts writes but can never commit them — no majority is reachable. The majority side times out, elects a fresh leader in a higher term, and keeps serving. Heal the partition and the old leader hears the higher term, steps down, and its uncommitted entries are truncated and replaced by the new leader's log. Notice the term counter inflating while a side lacks quorum — its candidates keep timing out and re-campaigning. Harmless here, but it's exactly the disruption the PreVote extension avoids in production systems.
Committed entries are never lost: a candidate must have a log at least as up-to-date as each voter's to win, and any majority contains at least one node holding every committed entry — so the winner always carries them forward. Availability needs ⌈(N+1)/2⌉ nodes alive; kill more and the cluster simply stalls rather than diverging.