How Raft consensus works
Trace Raft through leader heartbeats, randomized elections, majority voting, log replication, commit rules, failover, and repair.
The whole story in 5 lines
See how heartbeats, election timeouts, votes, log replication, majority commit, failover, and stale leader repair preserve one history.
- Regular leader heartbeats keep followers in the same term and reset their randomized election timers.
- When heartbeats stop, the first follower whose randomized timer expires increments the term and becomes a candidate.
- A candidate wins only with a majority and only when voters judge its log at least as up to date as their own.
- A leader commits a log entry after replication to a majority, then applies entries in order to the state machine.
- A returning node adopts the higher term and repairs any conflicting log suffix before rejoining normal replication.
Setup
Five servers hold the same account history, but the server accepting writes suddenly disappears. Raft is the recipe that helps the survivors choose a replacement without inventing two conflicting histories.
One server acts as the leader, so clients have a single place to send writes. The leader orders each command before asking the other servers to copy it.
The other servers are followers. Each follower copies the ordered log and can vote when leadership is uncertain, much like classmates preserving the same numbered notes.
A term is a numbered era for one election and its possible leader. A higher term tells every server that older claims to leadership are no longer current.
A quorum is a strict majority, such as three of five servers. Elections and commits both cross this boundary, which prevents two separate minorities from making conflicting decisions.
We will follow heartbeats, a timeout, a vote, one replicated command, and a failed leader returning with stale data. Let us begin with the quiet case where heartbeats keep one term stable.
Stable Term
Setup gave us one leader, several followers, and a numbered term. Here term 12 is stable because every follower still hears from the same leader.
The leader regularly sends an empty AppendEntries message called a heartbeat. It carries no new command, but it proves that term 12 still has an active leader.
Every follower receives that heartbeat at about the same moment and resets its local election timer. The simultaneous reset keeps the whole group calm without requiring a shared clock.
Between heartbeats, the follower timers climb independently. Their deadlines differ on purpose, so a later failure is less likely to make several followers campaign at once.
Another heartbeat reaches every follower before any deadline expires. All four timers drop together, making the quiet safety mechanism visible as a race that the leader keeps winning.
Heartbeats preserve a stable term by repeatedly beating every election deadline. Next, we will remove those messages and watch randomized silence turn one follower into a candidate.
Timeout Trigger
We just saw heartbeats reset every election timer. Now the leader is silent, so each follower keeps counting toward its own deadline with nothing to reset it.
Each follower chose a timeout from the same allowed range, but their exact deadlines differ. That randomness spreads the timers apart before anyone tries to lead.
One follower reaches its deadline first. It increments the cluster era from term 12 to term 13, changes into a candidate, and immediately votes for itself.
Several followers could otherwise start together and divide the votes again and again. Why does Raft randomize election timeouts?
The earliest timeout creates a brief head start. RequestVote messages now fan out from that one candidate while the other followers remain available to judge its request.
Randomized deadlines turn shared silence into one likely front runner, though they cannot guarantee an immediate winner. Next, we will inspect how a majority vote actually grants leadership.
Majority Vote
★ If you remember one thing · Two granted replies join the candidate's self vote to form a three of five quorum.
The timeout stage produced one candidate in term 13. It starts with its own vote, but that single mark does not grant authority over the cluster.
RequestVote messages reach every available peer. Each peer checks the candidate's term and log freshness before granting its one vote for this term.
The replies can converge on one candidate or split across rivals. What must a candidate receive to become leader for a term?
The replies converge and the tally reaches three votes. In this five server cluster, that strict majority crosses quorum and turns the candidate into the only elected leader for term 13.
Switch the Outcome control through both choices. Compare a majority converging on one leader against a split vote that leaves every candidate short of quorum.
A split vote elects nobody, so another randomized timeout starts a higher term. A majority creates one leader instead. Next, we will follow a client command through replication and commit.
Replicate + Commit
A majority has elected the leader for term 13. A client now sends one command to that leader, beginning the path from request to durable shared history.
The leader appends the command to its local log first. The new slot is still pending because one private copy cannot satisfy the quorum rule from Setup.
AppendEntries now fans the new slot out to both followers. This is the same message used for heartbeats, but its payload now extends each replicated log.
A follower stores the matching entry and sends an acknowledgment back. The leader counts replicated copies, so a slow follower can remain behind while the majority keeps moving.
The leader and one follower now hold the entry, which is a majority of this three server cluster. The commit index advances even though the other follower has not caught up.
Committed entries apply in order to the state machine, and a lagging follower catches up through later AppendEntries. Next, we will fail the leader and see how higher terms repair stale authority.
Failover + Rejoin
The previous stage committed data through a majority. Now the old leader fails while its log still contains extra tail entries that never reached quorum and never became committed.
A crash or network partition removes the old leader from quorum communication. The surviving followers stop receiving heartbeats, so their election timers begin the familiar race again.
The timeout mechanism repeats among the survivors. One follower starts term 13, gathers a fresh majority, and becomes the replacement leader without trusting the isolated node.
The replacement leader can accept and replicate new writes because the survivors still form a quorum. The old leader's private tail cannot overrule this newer majority history.
The old leader returns and sees term 13 from the replacement. That higher number immediately removes its authority, so it steps down before its stale suffix can spread.
AppendEntries rewinds the conflicting uncommitted tail and installs the replacement leader's entries. Now let us step back and connect heartbeats, elections, replication, and repair into one Raft story.
Recap
We started with a stable term. Regular heartbeats reset follower timers, so one active leader keeps the cluster from launching unnecessary elections.
Then the heartbeats stopped. Randomized deadlines gave one follower a head start, turning shared silence into a candidate for the next numbered term.
The candidate asked for votes next. Peers checked its term and log, while a strict majority separated an elected leader from an unresolved split vote.
The elected leader then copied each client command into replicated logs. A majority acknowledgment advanced the commit index without waiting for every follower.
Finally, failure triggered the same election machinery again. The returning old leader saw a higher term, stepped down, and replaced its uncommitted suffix with the majority history.
Together, these mechanisms preserve one ordered history across changing leaders. Raft links timing, majority authority, replicated logs, and repair so individual failures do not become conflicting committed decisions.
The whole story in 5 lines
See how heartbeats, election timeouts, votes, log replication, majority commit, failover, and stale leader repair preserve one history.
- Regular leader heartbeats keep followers in the same term and reset their randomized election timers.
- When heartbeats stop, the first follower whose randomized timer expires increments the term and becomes a candidate.
- A candidate wins only with a majority and only when voters judge its log at least as up to date as their own.
- A leader commits a log entry after replication to a majority, then applies entries in order to the state machine.
- A returning node adopts the higher term and repairs any conflicting log suffix before rejoining normal replication.