In Search of an Understandable Consensus Algorithm (Raft)

The claim

Paxos is correct but famously hard to understand; Raft achieves equivalent guarantees with a structure (strong leader, randomized election timeouts, log matching) that students can reproduce.

The mechanism, in one paragraph

A single leader per term accepts client writes, appends them to its log and replicates to followers; an entry is committed once a majority have it. Followers that stop hearing heartbeats start an election with a new term; the log-matching property plus the election restriction (only a candidate with an up-to-date log can win) keeps committed entries from being lost.

Where it matters for me

• Kubernetes: etcd is Raft. The leader-election timeouts explain why control-plane latency spikes during network partitions, which came up when I evaluated the move to Kubernetes described in infra-ops: one Terraform + Ansible platform for dev, staging and prod.
• Design taste: the paper's insistence on understandability as a first-class goal is the standard I hold architecture docs to; see the reasoning style in Designing Multi-Tenant Database Architectures.

Pairs with

Kleppmann's consensus chapter in Designing Data-Intensive Applications gives the context; this paper gives the algorithm.