Raft vs Paxos: same power, different bet

Paxos (Leslie Lamport, 1989, published readably in 1998) is a value-at-a-time consensus protocol with Proposer/Acceptor/Learner roles, described in a notoriously abstract way with no inherent persistent leader. Raft (Ongaro & Ousterhout, 2014) was explicitly designed for understandability: a strong, first-class leader handles all client requests and log replication, decomposing consensus into leader election, log replication, and safety as separate, more approachable sub-problems.

Unlike RAG-and-fine-tuning, this isn't a "use both" situation — a system picks one consensus algorithm. But the two didn't develop independently: Raft is essentially Paxos's ideas, restructured specifically for engineers to implement correctly, and understanding Paxos's proposer/acceptor formulation deepens why Raft's leader-election/log-replication split works as cleanly as it does.

The actual technical reason Raft feels easier isn't that it does less — it's that Raft makes a design commitment Paxos deliberately avoids: a STRONG LEADER. In Raft, only the current leader can append to the log, and it does so strictly in order, which means most of the hard reasoning collapses into two well-scoped questions: "how do we safely elect and maintain a leader," and "how does a new leader safely reconcile its log with the cluster after a crash" — each with its own formal proof in the Raft paper. Paxos's more general formulation, where any proposer can propose without a mandated order, is strictly MORE flexible — and that flexibility is exactly what later higher-performance variants (Multi-Paxos, Fast Paxos, EPaxos) exploited to reduce latency by avoiding always routing through a single leader.

But that same flexibility is what made the base protocol notoriously hard to get right in a real, partially-failing, network-partitioned production system — more edge cases, more ways for an implementation to be subtly wrong under an interleaving nobody tested. Raft trades away some of that theoretical flexibility for a protocol where the hard cases are fewer, named, and each has a proof — which is a real capability trade, not a free simplification.

etcd — the coordination store behind Kubernetes — needed a strongly-consistent, replicated store where the implementing engineers could reason with confidence about real edge cases: a leader crashing mid-write, a network partition happening during log replication, a new leader needing to safely reconcile a divergent log. These are exactly the scenarios Raft's decomposition names explicitly and proves safe for.

Raft's paper backs its understandability claim with more than intuition — a user study showed engineers implemented it correctly more often than Paxos given comparable material — and that evidence, not just theoretical elegance, was the deciding factor over adapting an existing Paxos implementation for a system as foundational to Kubernetes' reliability as etcd needed to be.