Five nodes. One total order to agree on. Some of them will fail. The network will lie. And somehow the system must keep ticking, keep accepting writes, and never serve two different stories. Raft is how the modern world solved it.
You have five servers. A client sends a write. How do you make sure all five agree on whether — and in what order — that write happened? Sounds trivial until you remember: any server can crash mid-conversation, the network can drop or duplicate any message, and clocks can disagree by hundreds of milliseconds (M.23). Now multiply the uncertainty by every concurrent client, every concurrent write, every reorganization caused by a node dying. This problem has a name. The name is consensus. The literature calls it "the hardest problem in distributed systems" for a reason.
What makes consensus hard isn't just the failure modes — it's that the algorithms to solve it are extraordinarily hard to get right. Lamport published the seminal solution (Paxos) in 1989, and for the next two decades the dominant feedback from implementers was: "we tried to build this and we couldn't." There's a famous 2007 Google paper, Paxos Made Live, where the engineers explain they had to write thousands of lines of code to make a "proven correct" algorithm actually work — and even then, edge cases kept emerging in production. Distributed consensus wasn't impossible. It was just impossible to teach.
Raft's revolution wasn't a new theoretical result. It was a pedagogical breakthrough. Ongaro & Ousterhout took the same problem Paxos solved — distributed consensus under crash failures — and decomposed it into pieces that human engineers could actually hold in their heads. Then they built a real implementation, ran user studies (literally — they tested how well students learned Raft vs Paxos), and showed Raft was dramatically more learnable. Within five years, virtually every new distributed system chose Raft over Paxos. etcd, Consul, CockroachDB, TiKV, ScyllaDB, Hashicorp Vault — the modern distributed world runs on Raft.
The rest of this module gives you Raft in the same decomposition the original paper uses: roles & terms (§02), the three sub-problems (§03), an interactive 5-node simulator that walks through normal operation and the failure modes (§04), and the safety properties Raft guarantees (§05). By the end you'll be able to read the etcd source code and recognize what every function is doing.
Raft's first design decision is to give every node one of three roles at any moment: Follower, Candidate, or Leader. Most of the time, exactly one node is a Leader and all others are Followers. This single-leader design is what makes Raft so understandable — once you accept that a leader exists, the work it must do is comparatively simple. The complexity is concentrated in electing a new leader when the old one fails, and the role machinery makes that explicit.
The default state. Receives AppendEntries from the leader (carrying log entries and heartbeats), votes on requests from candidates, but never initiates anything itself. Most nodes are followers most of the time.
A temporary state during elections. Increments the term number, votes for itself, and sends RequestVote RPCs to all other nodes. If it gets votes from a majority, it becomes the leader. If it sees a higher term, it steps down. If election times out, restarts.
Handles all client requests. Appends entries to its log and replicates them to followers via AppendEntries. Sends periodic heartbeats (also via AppendEntries, just with no new entries) to prevent followers from starting elections. Exactly one leader per term — guaranteed.
The other half of the role machinery is the term number. Every node tracks a current term — a monotonically increasing integer, starting at 0. Each election bumps the term by one. Terms are Raft's logical clock, in the Lamport sense from M.23: they let nodes detect stale information ("I'm hearing from a leader claiming term 5, but I know we're already on term 7 — that leader is from the past, ignore"). Every RPC carries a term number; receivers always compare it to their own. The rule is simple: higher term always wins, and on seeing a higher term, you immediately become a follower. This single rule eliminates entire classes of split-brain failures.
Worth pausing here: Raft is "leader-based" consensus. The leader is the bottleneck and the single point of decision. Some distributed systems philosophers find this offensive — surely true democracy means peer-to-peer with no leaders? — but the simplicity dividend is enormous. Raft solves the hard problem (agreement during failures) by reducing it, most of the time, to a one-machine problem: "the leader decides; everyone else just follows." Then the genuinely hard part is making sure a new leader emerges quickly and safely when the old one dies. That's where the meat of the algorithm lives, and that's what §03 unpacks.
The Raft paper's central pedagogical move is decomposing the consensus problem into three nearly-independent sub-problems. You can understand each one separately. Combine them and you get the full algorithm. The same decomposition is in the original paper's table of contents — and that table of contents is the curriculum every Raft tutorial follows.
Followers start election timers with randomized timeouts (150-300ms). When a timer expires without hearing from a leader, that follower becomes a candidate, increments the term, votes for itself, and sends RequestVote RPCs to every other node. The randomization breaks ties — usually one candidate's timer fires noticeably earlier, and it wins the election uncontested. If majority votes arrive, it becomes leader. If split-vote occurs (rare but possible), all candidates time out, randomize again, retry.
The leader appends client commands to its own log, then sends AppendEntries RPCs to all followers with new entries. Once a majority of followers acknowledge, the leader commits the entry (applies it to the state machine and tells the client). The next round of AppendEntries tells followers the new commit index, and they apply too. If a follower has fallen behind, the leader sends it the missing entries — going backward until it finds a matching point. This is essentially log shipping with majority quorum.
The hard one. Multiple invariants conspire to prevent the worst failures: election restriction (a candidate only wins if its log is at least as up-to-date as a majority), commit rule (a leader can only commit entries from its current term), log matching (if two logs agree on an index+term, they agree on everything before it). Together these guarantee that once an entry is committed, no future leader can ever lose or override it.
The Raft paper devotes about ten pages to each sub-problem. The simulator below walks you through three of those concretely — leader election from a cold start, log replication of a client write, and what happens when the leader fails. After you've stepped through all four scenarios, the algorithm in your head will match the algorithm in the paper. That's the whole goal of Raft's design.
Below: a 5-node Raft cluster. Pick a scenario. Step through the events one at a time. Watch nodes change state (F→C→L), terms increment, votes flow, log entries replicate. The right panel narrates what just happened and why. By the end of the four scenarios, the algorithm is concrete — not abstract.
The mechanics of leader election and log replication are easy to grasp. The deeper achievement of Raft is its safety guarantees — formally stated, formally proven, never broken even across the worst combination of failures. These are the properties that let etcd, Consul, and CockroachDB build production databases on top of Raft without paranoia. If any of these were violated, the cluster could lose or duplicate writes. They never are.
At most one leader can be elected in a given term. Because each node only votes once per term and a candidate needs majority to win, two candidates in the same term cannot both succeed — there aren't enough votes for both.
A leader never overwrites or deletes entries in its own log. It only appends new entries. This rules out an entire class of bugs where a confused leader could "edit history."
If two logs contain an entry with the same index and term, the logs are identical in all preceding entries. This is what makes AppendEntries's "previous entry check" work: matching just one index+term back proves all earlier history matches too.
If an entry is committed in term T, then all leaders of all higher terms contain that entry. Achieved by the election restriction: a candidate only wins if its log is at least as up-to-date as a majority. Committed entries are on the majority, so the next leader has them.
If a node has applied a log entry at a given index to its state machine, no other node will ever apply a different entry at that index. This is the "single truth" guarantee that consumers of Raft (etcd, etc.) rely on. Falls out from Properties 3 and 4.
The proof structure is worth knowing even if you'll never write it: Properties 1 and 2 are direct from the algorithm (votes are limited, leaders never delete). Properties 3, 4, and 5 build on each other: log matching enables leader completeness via the election restriction, and the two together give state machine safety. The whole stack is about two pages of proof in the original paper. Compare that to Paxos, where the equivalent proof spans dozens of pages across several papers. This is the second part of Raft's pedagogical win — not just that the algorithm is understandable, but that the safety arguments are too.
One thing Raft doesn't guarantee, worth flagging: liveness during arbitrary network conditions. If the network keeps dropping RequestVote messages in just the wrong way, the cluster can keep timing out, electing, timing out, electing, without ever stabilizing. In practice this is extraordinarily rare — the randomized timeouts make it nearly impossible — but in pathological networks, Raft (like all consensus protocols) trades liveness for safety. You'll never lose data; you might briefly be unable to make progress. That trade-off is correct, and it's the right one for the systems Raft serves.
Every term that appears in the Raft paper and every conversation about etcd, Consul, or CockroachDB. Lock these in.
floor(N/2) + 1. Needed both to win elections and to commit log entries. Two quorums always overlap, which is the mathematical foundation of safety.(term, index, command). Once committed (majority acknowledged), durable forever. The cluster's source of truth.AppendEntries. Entries below the commit index are applied to the state machine; entries above wait for majority.Test the Raft instinct. Click an answer; explanation drops in instantly.
Perfect. Raft's algorithm is now concrete in your head. Next: the broader replication landscape — multi-leader, leaderless, and what trade-offs each makes.
The consensus protocol that took over the distributed world. Every module forward will reference it.
Raft elects a single leader who makes all decisions. The cluster reduces to a one-machine problem most of the time. Simple to reason about — and the simplicity is the whole point.
Every election bumps a logical term clock. Higher term always wins; nodes seeing it immediately follow. This single rule prevents the worst class of distributed bugs.
Five safety properties. Two from the structure (one leader per term, append-only). Three from the math (log matching, leader completeness, state machine safety). The proof fits in two pages.