Raft vs Paxos: The Practical Consensus Guide

Every distributed system that claims to be strongly consistent must solve one fundamental problem: how do a set of independent nodes agree on a single sequence of operations, even when some nodes fail or messages are delayed? This is the distributed consensus problem, and for three decades it had exactly one widely-known solution: Paxos. Then, in 2013, Diego Ongaro and John Ousterhout published "In Search of an Understandable Consensus Algorithm"—and changed how the industry builds fault-tolerant systems.

A 2020 arXiv study, "Paxos vs Raft: Have we reached consensus on distributed consensus?" (arXiv:2004.05074), surveyed the production landscape and found that Raft has become the dominant consensus algorithm in newly built systems, displacing Paxos not because of superior theoretical properties, but because engineers can actually understand, implement, and debug it correctly. That finding matters enormously for anyone choosing a consensus approach for a new system in 2026.

Why Consensus Is Non-Negotiable in Distributed Systems

Consensus is the foundation of a specific class of guarantees: linearizability (operations appear to execute atomically in a single order), strong consistency (all reads see the most recent committed write), and fault tolerance (the system continues to function correctly despite node failures). Without consensus, you are either accepting eventual consistency or accepting the possibility of split-brain scenarios where two parts of a cluster disagree about the state of the world.

The practical applications are wide: distributed key-value stores (etcd, ZooKeeper), distributed databases (CockroachDB, TiKV), coordination services, distributed lock managers, and leader election in any replicated service. Anywhere you need multiple nodes to agree on a single authoritative state, you need a consensus protocol.

Paxos: The Original Algorithm

Leslie Lamport introduced Paxos in his 1998 paper "The Part-Time Parliament" (originally written in 1989). Its theoretical properties are impeccable: it guarantees safety (no two nodes commit different values for the same slot) under any message reordering and any number of non-Byzantine node failures up to a minority of the cluster.

The canonical Paxos protocol has two phases: in Phase 1, a proposer broadcasts a Prepare message to acceptors, gathering promises that they will not accept lower-numbered proposals; in Phase 2, the proposer sends an Accept message with the chosen value, and acceptors commit if no higher-numbered proposal has been prepared. A majority of acceptors must respond at each phase.

The problem is that basic Paxos only handles a single decision. Real systems need to agree on a sequence of operations (log entries), which requires extending the protocol to Multi-Paxos. The Multi-Paxos extension involves electing a stable leader, using the leader to skip Phase 1 for subsequent proposals, and handling leader failure. Lamport himself noted that Multi-Paxos has significant gaps that are left to implementers. The result, in practice, is that every organization that implemented Paxos ended up with a slightly different variant: Google's Chubby, Apache ZooKeeper (Zab, a Paxos variant), and various database consensus layers all differ in their details.

Image: File:Server Rack (54126210834).jpg — Tony Webster (CC BY 2.0), via Wikimedia Commons

Raft: Consensus Designed for Engineers

Raft was designed from first principles with one explicit goal: understandability. Ongaro and Ousterhout decomposed the consensus problem into three distinct sub-problems, each with a clean, independent solution: leader election, log replication, and safety.

Leader Election: Raft uses a randomized timeout approach. Every node starts as a follower with an election timeout (typically 150–300 ms). If a follower doesn't hear from a leader within its timeout period, it becomes a candidate, increments its term number, and sends RequestVote RPCs to peers. The first candidate to receive a majority of votes wins and becomes leader for that term. Randomized timeouts make simultaneous candidate elections (split votes) rare and self-resolving.

Log Replication: The leader accepts client requests, appends them to its local log, and replicates them to followers via AppendEntries RPCs (which also serve as heartbeats). An entry is committed once a majority of nodes have written it to their logs. Followers apply committed entries to their state machines in order. The leader tracks the highest committed index and includes it in all AppendEntries calls so followers can advance their commit pointers.

Safety Guarantee: Raft's key safety property is that a candidate cannot win an election unless its log is at least as up-to-date as the majority of the cluster. "At least as up-to-date" is defined precisely: the candidate's last log entry must have a higher term, or the same term but an equal or longer log. This ensures that the elected leader always has all committed entries, making leader transitions safe without log reconciliation.

Head-to-Head Comparison: Raft vs Paxos

Production Systems: Who Uses What

The adoption pattern in production systems as of 2026 strongly favors Raft for new systems:

etcd is the consensus backbone of Kubernetes. Every cluster state change—pod scheduling, service endpoints, configuration data—flows through etcd's Raft implementation. Its correctness and predictable behavior under network partitions have been battle-tested at massive scale.

CockroachDB and TiKV both use Raft consensus as the replication layer for their distributed SQL/key-value engines. CockroachDB uses a Raft group per range of data, allowing independent consensus for different data shards.

Consul by HashiCorp uses Raft for its service mesh coordination, KV store, and leader election features.

Image: File:Technician with laptop working on server rack at NERSC.jpg — Derrick Coetzee (CC0), via Wikimedia Commons

The legacy Paxos ecosystem remains significant: Apache ZooKeeper uses Zab (ZooKeeper Atomic Broadcast), a Paxos variant, and is still the coordination backbone for many older Hadoop-era systems. Google's internal infrastructure uses Paxos variants in Chubby and Spanner. But new systems built since 2015 have overwhelmingly chosen Raft or a Raft-inspired protocol.

Choosing Between Raft and Paxos in 2026

For most engineering teams building new systems, Raft is the right answer. The reasons are practical rather than theoretical:

First, mature Raft libraries exist in every major language: etcd's raft library in Go, raft-rs in Rust (used by TiKV), hashicorp/raft in Go (used by Consul), and various Java implementations. These are well-tested, well-documented, and have had years of production hardening.

Second, operational understanding matters. When your consensus layer behaves unexpectedly—and it will, at scale—engineers need to reason about leader election timeouts, log replication lag, and quorum failures. Raft's explicit decomposition of these concerns makes that reasoning tractable. With Multi-Paxos, the same debugging exercise often requires reading implementation-specific documentation because the protocol underspecifies too many behaviors.

Consider Paxos variants only if you have specific requirements: you're integrating with an existing ZooKeeper infrastructure, you need leaderless consensus variants for lower latency in geo-distributed deployments (EPaxos, Flexible Paxos), or your team has deep existing expertise in a specific Paxos implementation.

Frequently Asked Questions

Is Raft theoretically equivalent to Paxos?

Yes, in terms of safety properties. Both guarantee that no two nodes commit different values for the same log position, and both require a quorum (majority) to make progress. The 2020 arXiv paper "Paxos vs Raft" (arXiv:2004.05074) formally confirms they are equivalent in their core safety and liveness guarantees. The differences are in how they specify and implement leader election and log management—Raft is more prescriptive, Paxos is more flexible but underspecified.

What's the minimum cluster size for Raft/Paxos?

Both require a majority quorum. For a cluster to tolerate 1 node failure, you need 3 nodes (any 2 form a majority). For 2 node failures, you need 5 nodes. Two-node clusters provide no fault tolerance for consensus purposes—one failure eliminates the quorum. Most production deployments use 3 or 5 nodes depending on the acceptable failure tolerance.

How does Raft handle network partitions?

In a network partition, the partition containing the majority of nodes continues to function normally. The minority partition stops accepting writes (it cannot form a quorum) and is safe—it cannot commit anything. When the partition heals, the minority-partition leader (if one existed) discovers a higher-term leader on the majority side through normal heartbeat exchange, steps down, and brings its log into sync via the AppendEntries mechanism. This is one of Raft's cleanly specified behaviors versus the underspecified partition behavior in basic Paxos.

Bottom Line

We recommend Raft as the default consensus algorithm for any new distributed system in 2026. The production ecosystem, the quality of available libraries, and the operational debuggability of a well-specified protocol give Raft a clear practical advantage over Multi-Paxos for teams without existing Paxos expertise. For teams maintaining legacy Paxos-based infrastructure or building advanced geo-distributed systems, Paxos variants like EPaxos or Flexible Paxos remain relevant—but for greenfield work, Raft has genuinely won the engineering consensus that Paxos long held on the theoretical side.

Disclaimer: This article is for informational purposes only. Technology landscapes change rapidly; verify information with official sources before making technical decisions.