Raft is often described as 'Paxos, but designed to be understandable.' Concretely, what problem does Raft's strong-leader approach solve relative to classic Multi-Paxos, and what does that design choice cost?

## Where classic Paxos leaves off Paxos, as originally published by Leslie Lamport, specifies a two-phase protocol (Prepare/Promise, then Accept/Accepted) for getting a group of nodes to agree on a single value, using ballot numbers to resolve conflicts between competing proposers. It's provably correct and foundational, but the base algorithm ('single-decree Paxos') only agrees on one value ever - to build a real replicated log (needed for something like a database or a coordination service), you need 'Multi-Paxos': running many independent instances of Paxos, one per log slot, plus additional machinery to make that efficient and to decide who proposes for each slot. Critically, the original Paxos papers describe the reduction from single-decree to multi-decree only sketchily, leaving decisions like these as exercises for the implementer: - **leader election**, - **log-slot numbering**, and - **reconfiguration**. Different teams built genuinely different, incompatible Multi-Paxos variants, and even experienced engineers found translating the proof into a correct, complete system difficult - this is the exact gap Google's engineers documented in their well-known account of building Chubby, describing a nontrivial amount of unspecified engineering needed to get from the algorithm to a production system. ## What Raft makes first-class Raft, published by Diego Ongaro and John Ousterhout specifically with an explicit goal of understandability, closes that gap by making **strong leadership** a first-class, fully specified part of the algorithm rather than an implementation detail bolted on afterward. - In Raft, there is always at most one leader per term, and only that leader may append new entries to the log or decide the order of operations. - Followers never independently propose entries, they only replicate what the leader sends them, and clients are redirected to the current leader if they contact a follower. - Leader election, log replication, and the safety argument for why a newly elected leader is guaranteed to have all previously committed entries (**Leader Completeness**, enforced by the rule that a node votes only for a candidate whose log is at least as up-to-date as its own) are all specified as one integrated mechanism with a complete proof, and the original paper deliberately includes a full reference-quality specification, not just a proof sketch. This is why Raft became the default choice for many newer systems (etcd, Consul, CockroachDB's Raft layer, TiKV) - not because it's more powerful than Paxos, but because it's dramatically easier to implement correctly and to reason about when something goes wrong in production. ## The concrete cost, in two parts The concrete cost of centralizing all proposing through a single leader is twofold. 1. **First, throughput and latency are bounded** by that one leader's capacity to send and receive messages with a majority of followers - Raft doesn't allow, say, two different nodes to concurrently propose two different log entries for two different slots the way some Multi-Paxos variants permit (which can pipeline multiple concurrent proposals from different proposers when there's no leader contention). In practice this rarely matters for typical replicated-log workloads because a healthy single leader's network round trips to a handful of followers are fast, but it is a real theoretical ceiling that more flexible leaderless or multi-proposer designs (or protocols like EPaxos, explicitly designed to avoid a single-leader bottleneck) don't share. 2. **Second, every leader failure** - crash, network partition, or even just a slow node losing its position - triggers a full election: followers must individually notice missed heartbeats (after their randomized election timeout, typically on the order of 150-300ms in common implementations), a candidate must campaign and collect a majority of votes, and only then can new entries start committing again. During that window, the cluster is fully unavailable for writes, even though most of it is healthy - a startup cost Paxos-based systems that don't insist on a single stable leader can sometimes avoid, at the cost of the coordination complexity Raft was designed to eliminate. ## The choice teams actually make In production terms, this trade-off shows up as a deliberate choice: teams building a new coordination or metadata service today overwhelmingly reach for Raft (or a Raft-based product like etcd) specifically because getting a correct Multi-Paxos implementation from scratch is a known engineering risk, even though a well-tuned Paxos-family system can theoretically offer more flexible proposing patterns and, in some variants, lower tail latency by not always routing through one node. The understandability Raft optimizes for is not just an academic nicety - it directly reduces the chance of a subtle, hard-to-find bug in the exact code path responsible for a system's core correctness guarantee, which is a cost most engineering organizations are happy to pay the leader-bottleneck price for. ## A practical mitigation A practical mitigation worth knowing: Raft's single-leader throughput ceiling applies **per replicated log**, not per cluster as a whole. Real systems scale write throughput by sharding data across many independent Raft groups, each with its own leader, so aggregate throughput grows with the number of shards even though any single shard's writes still funnel through one leader at a time - this is exactly how systems like CockroachDB and TiKV scale far beyond what a single Raft group could handle.