Raft vs Paxos

Code / pseudocode side-by-side

Both protocols commit an entry once a leader (or proposer) collects acknowledgements from a majority. Here is the shape of a single "commit a log entry" round in each:

// Leader for term T replicates entry E
for each follower:
  send AppendEntries(term=T, prevLogIndex,
                      prevLogTerm, entries=[E])

// Follower accepts only if:
if req.term < currentTerm: reject
if log[prevLogIndex].term != req.prevLogTerm:
  reject  // log doesn't match, ask for backtrack
else:
  append(entries)
  reply(success=true)

// Leader commits E once a MAJORITY of
// followers have replied success=true

// Proposer picks ballot number N, value V
// Phase 1: Prepare
send Prepare(N) to all acceptors
// Acceptor promises not to accept < N
// and returns any value it already accepted

// Phase 2: Accept
// If a majority promised, proposer sends:
send Accept(N, V') to all acceptors
// (V' = highest-numbered value already
//  accepted by any acceptor, or V if none)

// Value is CHOSEN once a MAJORITY
// of acceptors accept (N, V')

When to reach for Raft

• You are building or choosing infrastructure from scratch. etcd, Consul, and hashicorp/raft give you a battle-tested, interoperable implementation with clear docs.
• Your team needs to reason about failure scenarios. Raft's explicit follower/candidate/leader states and term numbers make split-brain and network-partition behaviour much easier to trace in an incident review.
• You want strong consistency for configuration or coordination data. Kubernetes' control plane, service discovery, and distributed locks are the classic Raft use case — a small amount of critical state that must never diverge.
• You are teaching or onboarding engineers onto distributed systems. Raft's thesis was written explicitly to be teachable; use it as the reference model even if your production system runs something else.

When Paxos (or a Paxos variant) still shows up

• You are integrating with an existing Paxos-based system. Google Chubby, Spanner, and many internal Google services are built on Paxos; if you work in that ecosystem you inherit its vocabulary.
• You need Paxos's more flexible leaderless mode. Base Paxos does not require a single stable leader, which can matter for certain multi-datacentre designs that want to avoid a single point of coordination for proposing values.
• ZooKeeper is already in your stack. ZooKeeper's ZAB protocol is a Paxos-family, leader-based atomic broadcast protocol — you get Paxos-style guarantees through a mature, widely deployed coordination service without implementing consensus yourself.
• Academic or research contexts. Paxos remains the canonical reference for proving new consensus variants correct — most published extensions (Fast Paxos, Generalized Paxos, EPaxos) compare themselves against it, not Raft.

English phrases engineers use

Quick decision tree

• Building new coordination infrastructure from scratch → Raft (etcd/raft, hashicorp/raft)
• Need a battle-tested library with clear documentation → Raft
• Already running ZooKeeper or Chubby-style systems → Stick with the existing Paxos-family protocol
• Teaching consensus to a team new to distributed systems → Start with Raft's model
• Researching or extending consensus theory → Compare against Paxos, the academic baseline
• Need a leaderless mode for a specific multi-region design → Consider base Paxos or EPaxos