Module 13 · Distributed fundamentals · Lesson 13 of 18
Raft
Consensus organised around a strong leader and a contiguous log. Terms and randomized election timeouts, log replication and the commit rule, the election restriction that keeps committed entries safe, snapshots and membership changes.
The video walkthrough is part of Pro.
See what Pro includesWhy it matters
Raft is the consensus algorithm you are most likely to run: etcd (and therefore Kubernetes), Consul, CockroachDB, TiKV, Nomad, RabbitMQ quorum queues and many others use it. It was designed so that engineers could understand it end to end, which also makes it the version of consensus interviewers expect you to walk through. If you can explain how Raft elects a leader, replicates a log and never loses a committed entry, you can reason about the behaviour of every system built on it.
The idea
Raft decomposes consensus into leader election, log replication and safety, and runs them with three node states: follower, candidate and leader. Time is divided into terms, each with at most one leader, numbered monotonically. Every message carries the sender's term, and a node that sees a higher term immediately updates its own and steps down to follower.
Leader election
- 1
Followers wait for heartbeats
The leader sends periodic AppendEntries (heartbeats). A follower that hears nothing for a randomized election timeout (say 150 to 300 ms) assumes the leader is gone. - 2
Become a candidate
It increments its term, votes for itself and sends RequestVote to all nodes. - 3
Followers vote once per term
A node grants its vote if it has not voted in this term and the candidate's log is at least as up to date as its own (last entry's term higher, or equal term and longer log). This is the election restriction. - 4
Majority wins
A candidate with votes from a majority becomes leader and starts sending heartbeats. If two candidates split the vote, both time out and retry; randomized timeouts make repeated splits unlikely.
Log replication
Clients send commands to the leader, which appends each to its log as an entry (index, term, command) and sends AppendEntries to followers. Followers append the entry if the preceding entry matches (same index and term), otherwise reject, and the leader backs up to find the last matching point and overwrites the follower's divergent suffix. An entry is committed once the leader has replicated it to a majority (and it belongs to the leader's current term); the leader advances its commit index, applies the command to its state machine, replies to the client, and tells followers the new commit index in subsequent heartbeats so they apply too.
Safety: why committed entries survive
Two properties together guarantee that a committed entry is never lost or overwritten. The election restriction means only a candidate whose log contains every committed entry can win (any committed entry is on a majority, and the candidate needs votes from a majority, which must include a node that has the entry and will refuse a less up-to-date candidate). The leader append-only rule means a leader never overwrites its own entries, and the matching property means logs that agree at an index agree on everything before it. Together: once committed, an entry is present in every future leader's log, at the same index.
Operating details
Snapshots compact the log: a node writes its state machine image plus the last included index and term, discards earlier entries, and a lagging follower can be sent the snapshot instead of the full log. Membership changes use joint consensus or single-server changes so that no two disjoint majorities can exist during the transition. Read-only queries need care: a leader must confirm it is still leader (a heartbeat round or a lease) before serving a linearizable read, or the read may be stale from a deposed leader. Pre-vote stops a partitioned node from disrupting the cluster with ever-higher terms when it rejoins.
| Setting | Typical value | Trade-off |
|---|---|---|
| Heartbeat interval | 50 to 100 ms | Lower detects failures faster at the cost of traffic |
| Election timeout | 5 to 10× heartbeat, randomized | Too low causes spurious elections; too high delays failover |
| Cluster size | 3 or 5 | Five tolerates two failures with more replication cost |
| Snapshot threshold | Thousands of entries or tens of MB | Frequent snapshots cost I/O; rare ones make recovery slow |
| Linearizable reads | Lease-based or read-index | Leases depend on bounded clock drift; read-index costs a round |
In production
etcd stores Kubernetes state; a three- or five-node cluster handles thousands of writes per second with single-digit millisecond commits. CockroachDB and TiKV run one Raft group per data range, thousands of groups per cluster, which is how they scale consensus horizontally. Consul uses Raft for its catalogue and KV store. Kafka's KRaft replaced ZooKeeper with a Raft-based controller quorum. All inherit Raft's operational shape: odd sizes, leader-bound write throughput, minority-side unavailability under partition.