Paxos and Raft: The Engines of Consensus

Consensus is the core challenge of distributed systems: ensuring that a cluster of non-trusting or failing nodes can agree on a single value or a sequence of operations. This agreement is required for Leader Election and State Machine Replication (SMR).

Two algorithms dominate the field: Paxos, the mathematically flexible original, and Raft, the "understandable" successor.

1. Paxos: The Theoretical Powerhouse

Proposed by Leslie Lamport in 1989, Paxos is a family of protocols designed for total flexibility.

Core Paxos Roles

Proposer: Receives client requests and attempts to convince the cluster to accept them.
Acceptor: Votes on proposals and acts as the durable memory of the cluster.
Learner: Learns the outcome of the vote and applies it to the state machine.

Multi-Paxos and Optimization

Standard Paxos agrees on only one value. Multi-Paxos chains these agreements together to form a log. In 2026, Multi-Paxos is preferred for high-performance systems because it allows for:

Out-of-Order Confirmation: Unlike Raft, Multi-Paxos can confirm log index $N+1$ before $N$ , allowing for massive pipelining.
WAN Flexibility: Variants like Fast Paxos can save network round-trips (RTTs) in global deployments by allowing any node to initiate a proposal.

2. Raft: Design for Understandability

Introduced by Ongaro and Ousterhout in 2014, Raft was designed specifically to be easier to implement correctly than Paxos.

The Strong Leader

Raft centers all activity around a Strong Leader.

Leader Election: Nodes use randomized timeouts to elect a leader.
Log Replication: The leader receives commands, appends them to its local Write-Ahead Log (WAL), and replicates them to followers.
Safety: Raft ensures that a node can only be elected leader if it contains all previously committed log entries.

Head-of-Line Blocking

Because Raft enforces a strict sequential log order, a single slow follower or a lost packet can stall the entire pipeline. This makes Raft slightly less performant than Multi-Paxos at extreme scales.

3. Technical Comparison (2026 Standards)

Feature	Multi-Paxos	Raft
Philosophy	Theoretical Flexibility	Understandable Integrity
Throughput	Higher (Pipelining / Out-of-order)	Moderate (Strict sequentiality)
Recovery	Predictable (Deterministic)	Variable (Randomized timeouts)
WAN Usage	Preferred (Fast Paxos variants)	Limited (Leader bottleneck)
Impl. Risk	Extreme ("Paxos Made Live")	Low (Mature libraries like `etcd`)

4. Selection Framework: Which should you use?

Choose Raft if you are building metadata services, configuration stores (like consul or etcd), or standard business microservices. The performance difference is negligible for 95% of applications, and implemented safety is guaranteed.
Choose Paxos if you are building a high-performance distributed database (like Spanner, OceanBase, or TiDB) where Tail Latency in multi-region deployments is your primary competitive constraint.