Archivedistributed-systems
Raft in One Page
Leader election, log replication, and safety — the three mechanisms that make Raft teachable.
- Published
- Reading time
- 1 min read
Raft decomposes consensus into leader election, log replication, and safety, with terms as a logical clock.
Roles and terms
Every node is follower, candidate, or leader. Time increments in terms. A follower that hears nothing from a leader for a randomized election timeout becomes a candidate, increments the term, and requests votes. A candidate with a majority becomes leader for that term.
Randomized timeouts (e.g. 150–300 ms) make split votes rare without a coordinator.
Replication
The leader appends client commands to its log and sends AppendEntries to followers. An entry is committed once stored on a majority and the leader has committed an entry from its current term. Followers learn the commit index from subsequent heartbeats.
Election restriction: a candidate may only win if its log is at least as up-to-date as the voter's. This is what prevents a minority with stale entries from taking over.
The parts people get wrong
- Committing entries from previous terms by counting replicas — the "Figure 8" bug. Always commit via a current-term entry.
- Snapshotting without preserving term/index metadata.
- Ignoring the read path: linearizable reads need a leader lease or a read-index round.
Takeaway: Raft is simple to describe and subtle to implement. Use a proven library and test with partitions, not just process crashes.