Designed to be Understood
For many years, Paxos was the only well-known consensus algorithm. But its complexity was a major barrier — teams implementing Paxos often introduced subtle bugs that only manifested under rare failure conditions. In 2013, Diego Ongaro and John Ousterhout published Raft with a primary design goal stated explicitly in the paper: understandability.
Raft is mathematically equivalent to Multi-Paxos in what it achieves — it provides the same safety and liveness guarantees — but it structures the problem differently to make it easier to reason about, implement, and teach.
Raft decomposes consensus into three independent subproblems:
1. Leader Election: The cluster must select exactly one node to be the leader at any given time.
2. Log Replication: The leader must accept commands from clients and replicate them to all followers in a consistent order.
3. Safety: A set of invariants that ensure committed entries are never lost, even across leader changes.
This decomposition makes Raft much easier to learn and implement correctly, leading to its widespread adoption in production systems:
| System | Uses Raft Via |
|---|---|
| Kubernetes | etcd |
| Consul | Built-in Raft |
| CockroachDB | Built-in Raft |
| TiKV (TiDB) | Built-in Raft |
| InfluxDB | Built-in Raft |
A common interview question is: "What is the difference between Raft and Paxos?" The key answer: they provide equivalent safety guarantees, but Raft achieves this through a more structured decomposition (leader election → log replication → safety rules) that makes it significantly easier to implement correctly. Raft also specifies cluster membership changes explicitly, which Paxos leaves underspecified. In practice, "Paxos" in production systems almost always means a heavily modified Multi-Paxos variant that ends up looking a lot like Raft anyway.