Raft consensus

Raft cuts time into numbered terms, and each term starts with a leader election ¹. A follower that hears no heartbeat for its election timeout increases the term counter, votes for itself and asks every other server for its vote ². Each server votes once per term ³, a candidate with a majority becomes leader ⁴, and because the timeout is randomized, split votes are resolved quickly ⁵. etcd defaults to a 100 ms heartbeat and a 1000 ms election timeout ⁶⁷.

Every write goes to the leader, which appends it to its log and replicates it to the followers ¹. An entry is committed once it is durably stored on a majority, and only then is it applied ². So 5 servers keep working with 2 down; with 3 down they stop making progress, but never return a wrong result ³⁴. After a leader crash, the new leader repairs any mismatch by forcing the followers to duplicate its own log ⁵.

Raft was published at USENIX ATC 2014 as an algorithm for managing a replicated log, equivalent to Paxos in fault tolerance and performance ¹². It separates leader election, log replication and safety, and in a user study students learned it more easily than Paxos ³⁴. The etcd Raft library powers etcd, Kubernetes and Docker Swarm, among others ⁵.