What is the Raft Consensus Algorithm?
Learn how the Raft consensus algorithm works: leader election, log replication, and majority commits for distributed systems.
Expected Interview Answer
Raft is a consensus algorithm that lets a cluster of nodes agree on a single, replicated sequence of operations by electing one leader per term who owns all writes, replicates them to followers via a log, and only commits an entry once a majority of nodes have durably stored it.
Raft splits the consensus problem into three understandable sub-problems: leader election, log replication, and safety. Every node is a follower, candidate, or leader; if a follower stops hearing heartbeats within a randomized election timeout, it becomes a candidate, increments the term, and requests votes. Once a candidate wins a majority, it becomes leader for that term and is the only node allowed to accept client writes, appending each write to its log and replicating it to followers before acknowledging the client. An entry is considered committed only after it exists on a majority of nodes, which guarantees it survives future leader crashes, and Raft’s election rules (a candidate must have a log at least as up to date as a majority of voters) prevent a node with stale data from ever becoming leader and overwriting committed entries.
- Provides a strongly consistent replicated log that survives minority node failures
- Is deliberately easier to reason about and implement correctly than Paxos
- Guarantees committed entries are never lost or overwritten by a new leader
- Underpins production systems like etcd, Consul, and CockroachDB
AI Mentor Explanation
Raft is like a team electing a single captain for the season instead of every player independently deciding tactics on the field. If the captain stops communicating (heartbeats stop arriving), any player can call for a fresh captaincy vote, and whichever nominee gets backing from more than half the squad becomes the new captain for that season (term). Once the captain calls a tactic, it only becomes official team policy after a majority of players have written it into their playbooks, so no single missing player can undo it. This majority-write-then-commit rule is exactly how Raft keeps the whole squad’s playbook consistent even when players drop in and out.
Step-by-Step Explanation
Step 1
Elect a leader
When followers stop hearing heartbeats within a randomized election timeout, they become candidates, increment the term, and request votes; whoever wins a majority becomes leader.
Step 2
Leader accepts writes
Only the current leader accepts client write requests, appending each as a new entry to its local log before replicating it.
Step 3
Replicate to followers
The leader sends AppendEntries RPCs to followers; each follower appends the entry and acknowledges once it is durably stored.
Step 4
Commit on majority
Once a majority of nodes (including the leader) have the entry, it is committed, applied to the state machine, and the client is acknowledged.
What Interviewer Expects
- Explains the leader/follower/candidate roles and randomized election timeouts
- Describes log replication and the majority-quorum commit rule
- Mentions terms and how they prevent split-brain / stale leaders
- Names real systems using Raft: etcd, Consul, CockroachDB
Common Mistakes
- Confusing Raft with simple primary-replica replication without quorum guarantees
- Forgetting that a candidate needs an up-to-date log to win an election
- Not explaining why a majority (not all nodes) is required to commit an entry
- Mixing up Raft terms with wall-clock time instead of monotonically increasing counters
Best Answer (HR Friendly)
“Raft is a way for a group of servers to agree on the same sequence of changes even if some of them fail. One server is elected leader and takes all the writes, copies them to the others, and only considers a change final once more than half the servers have saved it, so the system keeps working correctly even if a few machines go down.”
Code Example
class RaftNode:
def __init__(self, node_id, peers):
self.node_id = node_id
self.peers = peers
self.current_term = 0
self.voted_for = None
self.role = 'follower'
self.log = []
def start_election(self):
self.role = 'candidate'
self.current_term += 1
self.voted_for = self.node_id
votes = 1 # vote for self
for peer in self.peers:
if peer.request_vote(self.current_term, self.node_id, len(self.log)):
votes += 1
if votes > (len(self.peers) + 1) / 2:
self.role = 'leader'
def append_entry(self, command):
if self.role != 'leader':
raise Exception('only the leader accepts writes')
entry = {'term': self.current_term, 'command': command}
self.log.append(entry)
acks = 1 # leader counts itself
for peer in self.peers:
if peer.append_entries(self.current_term, entry):
acks += 1
if acks > (len(self.peers) + 1) / 2:
return 'committed'
return 'pending'Follow-up Questions
- How does Raft prevent a node with a stale log from becoming leader?
- What happens if the network partitions and two subsets each think they have a leader?
- How does Raft compare to Paxos in terms of understandability and message complexity?
- How does log compaction (snapshotting) work in a long-running Raft cluster?
MCQ Practice
1. In Raft, when is a log entry considered committed?
Raft commits an entry once a majority (quorum) of nodes have durably stored it, guaranteeing it survives future leader failures.
2. What triggers a follower in Raft to start a new election?
Followers become candidates and start an election when they stop hearing leader heartbeats within their randomized timeout window.
3. Why does Raft use randomized election timeouts across nodes?
Randomizing timeouts reduces the likelihood of simultaneous candidacies that would split votes and delay leader election.
Flash Cards
What is Raft? — A consensus algorithm where a leader replicates a log to followers and commits entries once a majority store them.
What are the three Raft node roles? — Follower, candidate, and leader.
When is an entry committed in Raft? — Once a majority of nodes have durably stored it in their log.
Why does Raft use terms? — Monotonically increasing terms detect stale leaders and prevent split-brain writes.