Raft is a distributed consensus algorithm designed explicitly for understandability, introduced by Diego Ongaro and John Ousterhout at USENIX ATC 2014 as a more comprehensible alternative to the Paxos family of protocols. Raft decomposes the consensus problem into three relatively independent sub-problems: leader election, log replication, and safety. A Raft cluster maintains a replicated log of commands through a strong leader that serialises all writes; followers replicate the leader’s log entries and redirect client requests. Leader election uses randomised timeouts to avoid split votes. Raft has become the dominant consensus algorithm in modern distributed systems infrastructure, underpinning etcd, CockroachDB, TiKV, Consul, and many other widely deployed systems.
Content
- Raft was introduced in 2014 with a central goal explicitly stated in the paper title: “In Search of an Understandable Consensus Algorithm.” The authors conducted user studies comparing understanding of Raft against Paxos and found statistically significant advantages for Raft comprehension, validating their design choices. The motivation for prioritising understandability was practical: consensus algorithms are notoriously difficult to implement correctly, and subtle bugs in consensus code can cause data loss in production systems.
- The leader election mechanism in Raft uses terms, which are monotonically increasing logical time counters. Each server starts as a follower and transitions to candidate if it does not receive a heartbeat from a leader within a randomised election timeout period. A candidate requests votes from other servers; a server grants a vote to a candidate only if the candidate’s log is at least as up-to-date as the voter’s log. The randomised timeout ensures that in practice one server starts an election before others and wins with high probability, avoiding split vote scenarios that require retries.
- Log replication is the core operation: the leader accepts client commands, appends them to its log, and sends AppendEntries RPC calls to all followers in parallel. A log entry is committed once a majority of servers have acknowledged storing it. This majority quorum guarantee means that any two majorities overlap in at least one server, ensuring that a newly elected leader always has all committed entries. The replicated log drives a deterministic state machine on each server, producing the replicated state machine semantics that make Raft useful as a coordination primitive.
- The etcd key-value store, used as the primary data store for Kubernetes cluster state, implements Raft as its consensus backend and has made Raft one of the most battle-tested consensus implementations in production. CockroachDB uses Raft to replicate ranges of its distributed key-value store, with each range having its own Raft group, allowing fine-grained replication and fault-tolerance configuration. Consul uses Raft for its leader-elected agent coordination.
- Raft has been extended by researchers and engineers to handle various practical concerns: multi-Raft allows many independent Raft groups to coexist efficiently in a single process, as used in TiKV; joint consensus mechanisms support cluster membership changes (adding or removing servers) without availability gaps; and pre-vote extensions reduce disruptive elections caused by network-isolated servers with stale terms. These extensions demonstrate the value of Raft’s clear design as a foundation for controlled incremental complexity.