Give the intuition behind consensus algorithms like Raft — how do distributed nodes agree on a single value?
No single node can be trusted to decide alone — Raft shows how a majority of unreliable machines agree on one truth, even as leaders crash and networks split.
LEARN BY DOINGPut your intuition to work3 steps
Give the intuition behind consensus algorithms like Raft — how do distributed nodes agree on a single value?
Use the lesson’s examples and explanation to check your idea.
Personal reflection. Nothing is sent to an AI service.#Why "just pick a leader" isn't the whole answer
The obvious way to get several machines to agree on something is to elect one of them the leader and let it decide. That much is easy. The hard part is everything that happens once you accept that leaders crash, networks partition, and messages get delayed or lost — and that the system still has to make progress without ever letting two nodes believe they're both the legitimate leader at the same time and issue conflicting decisions. That guarantee, under those failure conditions, with no single point of control that isn't itself replaced when it fails, is the consensus problem. Raft is the algorithm most systems reach for to solve it, specifically because it was designed to be understandable — its predecessor, Paxos, is at least as powerful but notoriously difficult to implement correctly from the paper alone.
#The three roles and the term
Every node in a Raft cluster is in exactly one of three states at any moment: Follower (the default — passive, responds to the leader and to candidates, never initiates anything), Candidate (a temporary state while campaigning for votes), or Leader (handles every client request and drives log replication). Time is divided into terms — a monotonically increasing integer that increments every time a new election starts. A cluster has at most one leader per term, and every message carries its sender's current term, which is how nodes detect that they're behind and need to step down or update.
#Leader election
Followers expect a heartbeat from the leader at a steady interval, delivered as an AppendEntries RPC that can be empty. If a follower doesn't hear from a leader within a randomized election timeout — commonly something like 150 to 300 milliseconds, with the randomization deliberately different per node — it assumes the leader is gone, transitions to Candidate, increments its term, votes for itself, and sends RequestVote RPCs to every other node in parallel.
A node grants at most one vote per term, first-come-first-served, and only if the candidate's log is at least as up to date as its own — a safety check that prevents a node with a stale log from ever becoming leader and silently erasing already-committed work. If a candidate collects votes from a majority of the cluster, it immediately becomes leader for that term and starts sending heartbeats, which both establishes its authority and resets every follower's election timer.
The randomized timeout is what keeps this from deadlocking. If every follower's timeout were identical, multiple nodes could time out simultaneously, split the vote so no one reaches a majority, and repeat forever. Randomization makes it overwhelmingly likely that one follower times out meaningfully before the others, campaigns, and wins before a second candidate even enters the race. A genuine split vote can still happen occasionally — in that case, the term simply expires and every candidate retries with a fresh random timeout, which resolves it with high probability on the next attempt.
#Log replication
Once a leader is in place, every client write goes through it (a client that contacts a follower gets redirected to the current leader). The leader appends the command to its own log as a new entry tagged with the current term and its index, then sends it to every follower via AppendEntries, in parallel, alongside the term and index of the entry immediately preceding it.
A follower accepts the new entry only if its own log already matches the leader at that preceding position — the log matching property. If it doesn't (the follower is behind, or has stray uncommitted entries from a former leader), it rejects the append, and the leader backs up and retries with earlier entries until it finds a point where the logs agree, then overwrites everything after that point with its own version. This is the only way follower logs are ever allowed to diverge from the leader's and then get corrected — a leader may only append to its own log, never rewrite it.
An entry is committed the moment the leader confirms it's stored on a majority of nodes, including itself. At that point the leader applies it to its own state machine and responds to the client — durability is already guaranteed, because a majority has it, and no future leader can be elected without that majority's votes, which (by the up-to-date log check in the election) guarantees the entry survives into every subsequent leader's log. The leader then tells followers the entry is committed via the leaderCommit field on the next AppendEntries, so they apply it to their own state machines too.
Notice the client already got its OK after the majority ack — it does not wait for every follower, and it does not wait for the commit notification to round-trip back down. That's exactly what lets Raft make progress with a minority of nodes down or slow.
#The safety properties that make this trustworthy
| Property | Guarantee |
|---|---|
| Election Safety | At most one leader can be elected in a given term |
| Leader Append-Only | A leader never overwrites or deletes entries in its own log — only appends |
| Log Matching | If two logs contain an entry with the same index and term, every preceding entry in both logs is identical |
| Leader Completeness | Once an entry is committed, every future leader's log is guaranteed to contain it |
| State Machine Safety | If any server has applied a log entry at a given index to its state machine, no other server will ever apply a different entry for that same index |
Leader Completeness is doing the real work here, and it's enforced entirely inside the voting rule: a node refuses to vote for a candidate whose log is behind its own. Since winning requires a majority, and a committed entry already lives on a majority, any candidate that could win must have that entry (or a newer one covering it) already — a leader that lacks a committed entry mathematically cannot win an election.
#Quorum math and what a partition does to you
A cluster of 2f + 1 nodes tolerates f of them being crashed or unreachable while continuing to elect leaders and commit entries — a 5-node cluster survives 2 failures, a 3-node cluster survives 1. If a network partition splits a 5-node cluster into a group of 3 and a group of 2, the group of 3 can still reach a majority on its own and keeps serving writes; the group of 2 cannot reach a majority, so it can elect no leader and accepts no writes at all. It simply stalls until the partition heals, rather than accepting writes that would later conflict with the majority side. That's a deliberate choice to favor consistency over availability during a partition — the minority side is unavailable, but it is never wrong.
#Where you've actually used this
Raft (or a close variant) sits underneath etcd — which is what Kubernetes itself uses to store all cluster state — as well as Consul, CockroachDB's range replication, and TiKV. Anywhere you see a system advertise "strongly consistent replicated metadata" with automatic leader failover, there's a very good chance a Raft-like log sits underneath it.
🧠 Check your understanding
0/3 · 0/3 answered1. Why does Raft use a randomized election timeout instead of a fixed one for every node?
2. What must be true before a Raft leader considers a log entry "committed"?
3. A 5-node Raft cluster is split by a network partition into a group of 3 and a group of 2. What happens?