1. One leader speaks for the group
Clients send writes to the leader. Followers mostly copy what the leader says. This keeps ordering simple.
Raft In One Minute
If you remember only a few ideas, remember these.
2. Majority means safety
An entry is not safely committed just because one machine wrote it. It becomes committed only after a majority agrees.
3. Elections repair failure
If followers stop hearing from the leader, one starts an election. The cluster picks a new leader and continues.
4. Old leaders must give up
If a server sees a higher term, it steps down. This is one of the key reasons Raft avoids split-brain commits.
5. The log is the shared memory
The replicated log is the ordered history of decisions. Every healthy node should converge to the same committed log.
6. YugabyteDB scales with many leaders
YugabyteDB does not use one cluster-wide Raft leader. Each tablet has its own Raft leader, so work spreads across the cluster.
Guided Flow
Walk through the protocol in five detailed scenes.
Each scene has a simple explanation, a more technical explanation, and the operational lesson to remember. The details here were re-checked against the Raft project site, the Raft algorithm summary on Wikipedia, and YugabyteDB documentation.
Scene 1
Follower timeout starts a new term.
Plain English: if the current leader goes quiet for too long, one follower says, “I think the leader is gone. Let’s vote for a new one.”
A follower stops hearing heartbeats within its randomized election timeout, increments the term, votes for itself, and becomes a candidate.
Randomized timeout
Self-vote
New term
What happens
The follower starts a new election because it no longer trusts that a current leader is alive.
Why it matters
Fast leader replacement improves availability, but the random timeout reduces the chance that everyone starts an election at the same moment.
Interview answer
Randomized election timeout helps resolve split votes and stabilize leader selection.
A
Follower
term 7
B
Follower
term 7
C
Follower
term 7
A log
[1][2][3]
B log
[1][2][3]
C log
[1][2][3]
No leader heartbeat arrives in time, so one node advances the election.
Simple Mental Model
Think of Raft like a careful team taking notes together.
Leader
The leader is the current coordinator. It receives requests, writes them to the shared history, and asks others to confirm.
Followers
Followers are the witnesses. They copy the leader’s history and can quickly take over if the leader disappears.
Quorum
A majority is the “enough people agree” rule. If most of the group has confirmed an entry, a future leader will preserve it.
How To Use This
This subpage is meant for presentations, study sessions, and interview prep.
For teaching
Use the scenes to narrate exactly how a follower becomes candidate, how quorum works, and why stale leaders cannot safely continue writing.
For interviews
Pause on scene 4 to talk through minority partitions, stale leaders, and why Raft chooses safety over write availability without quorum.
For YugabyteDB
Use scene 5 to explain that the database scales through many tablet Raft groups and leader balancing rather than a single global leader.
Common Confusions
Things people often get wrong about Raft.
Replicated is not the same as committed
An entry can exist on several nodes and still not be safely committed. Commitment requires Raft’s quorum rules.
Two leaders may appear briefly
During a partition, two nodes may both think they are leader. The key safety point is that conflicting commits still require a majority, so the minority side cannot safely finalize writes.
Raft is not Byzantine fault tolerant
Raft handles crashes, restarts, and message delays, but it assumes the participating servers are not malicious.
Verification Notes
The content on this page was re-checked before this revision.
Verified facts used here include: Raft is designed for understandability, progress depends on a majority, leaders are elected after missed heartbeats, voters grant one vote per term, candidates need up-to-date logs, joint consensus is used for safe membership changes, log compaction uses snapshots, and YugabyteDB applies Raft per tablet rather than one global cluster log.