Raft is a distributed consensus algorithm designed as a more understandable alternative to Paxos, decomposing consensus into three relatively independent sub-problems: leader election, log replication, and safety. A Raft cluster elects a single leader by majority vote during which followers grant a term-limited mandate; the leader receives all client writes, appends them to its log, and replicates them to followers, committing entries once a quorum acknowledges receipt. Raft guarantees that committed entries are never lost as long as a majority of nodes remain connected, providing crash fault tolerance but not Byzantine fault tolerance.
Semantic Classification
Content
- Raft was introduced by Diego Ongaro and John Ousterhout in 2014 specifically to address the perceived understandability problem of Paxos, which is notoriously difficult to implement correctly from its original description. Raft’s key design decisions include: strong leader (all log entries flow through the leader, simplifying consistency reasoning); randomised election timeouts (each follower waits a random duration before starting an election, avoiding split-vote livelock); and log matching (if two logs have an entry with the same index and term, all entries up to that index are identical).
- Leader election proceeds by term number: when a follower detects a leader timeout, it increments its current term and sends RequestVote RPCs to peers. A candidate wins if it receives votes from a majority of the cluster; a node votes for a candidate only if the candidate’s log is at least as up-to-date as its own, ensuring that elected leaders always hold all committed entries. Once elected, the leader sends periodic AppendEntries RPCs (heartbeats) to prevent follower timeouts.
- Raft is widely deployed in production distributed systems: etcd (the Kubernetes configuration store), CockroachDB, TiKV (TiDB’s storage engine), and Consul all use Raft-based consensus. Permissioned blockchain frameworks such as Hyperledger Fabric support Raft as an ordering service consensus mechanism for crash fault-tolerant deployments. For Byzantine fault-tolerant environments (where nodes may behave arbitrarily or maliciously), alternative algorithms such as PBFT, HotStuff, or Tendermint are required instead.