Raft: one log, kept identical by a majority

What it is for. A group of machines must behave as one: a single source of truth, surviving the death of a minority, never splitting into two truths. This is the job inside coordination services (etcd, Consul), the metadata layer of distributed databases, and Kafka's built-in controller (KRaft).

The core idea: replicate the log, not the data. Every machine keeps the same ordered log of commands. Each machine derives its state by replaying the log from the top, so identical logs guarantee identical states. Raft's whole job reduces to keeping one log identical everywhere.

Roles and terms. One Leader (the only write entry point), the rest Followers. Time is divided into terms — monotonically increasing generation numbers. A message from an older term is always ignored, which retires stale leaders automatically.

Election. The leader proves it is alive with periodic heartbeats. A follower that hears nothing within a timeout concludes the leader is dead: it increments its term, becomes a Candidate, votes for itself and campaigns. A majority of votes elects the new leader. Two deliberate details: election timeouts are randomized per node, so followers do not all stand up at once and split the vote; and a voter only votes for a candidate whose log is at least as up-to-date as its own, which guarantees the new leader already carries every committed entry.

Replication and commit. A client write goes to the leader, which appends it (uncommitted), copies it to the followers, and marks it committed once a majority hold it — only then is it applied and the client answered. Majority is the safety catch twice over: any two majorities intersect, so a committed entry is necessarily present in any group that could elect the next leader; and under a network partition the minority side can neither elect a leader nor commit anything, so it stalls rather than diverging. On healing, its uncommitted leftovers are overwritten by the real log.

Costs. Clusters run odd-sized (3 tolerates 1 death, 5 tolerates 2; 4 tolerates only 1, so it buys nothing). Every write costs a round trip to a majority, and the leader is the write bottleneck — Raft agrees on one log, so large systems run many Raft groups, one per shard (multi-raft).

Raft vs ZAB. ZAB (ZooKeeper Atomic Broadcast, Yahoo, ~2008) is Raft's older cousin and powers ZooKeeper; Raft (Stanford, 2014) was designed afterwards, explicitly to be understandable. The skeleton is shared — leader, epoch/term, majority quorum, ordered log replication. The differences: (1) Birth purpose: ZAB was built as one product's primary-backup protocol with atomic broadcast; Raft as a general-purpose consensus algorithm meant to be taught and reimplemented. (2) Leader change: ZAB makes the transition an explicit ceremony — a separate election, then a discovery/sync phase in which the new epoch is established and histories are reconciled before any new broadcast. Raft folds this into its normal flow: the election restriction picks a candidate holding the committed prefix, and the AppendEntries consistency check forces followers' logs into line as replication resumes. (3) Where you meet them: ZAB almost only inside ZooKeeper; Raft spread everywhere — etcd, Consul, TiKV, CockroachDB, and Kafka replacing ZooKeeper with its own Raft (KRaft). (4) Both stand on Paxos's shoulders; Multi-Paxos is the common ancestor.