Questions: Raft Consensus Algorithm

Question 1

A Raft cluster has 5 nodes. The current leader and one follower become partitioned from the other three nodes. What happens in the partition containing three nodes?

• A. The three nodes wait indefinitely for the leader to return, since they do not know it has failed
• B. The three nodes elect a new leader from among themselves and continue processing client requests
• C. The three nodes cannot elect a leader because they lack full information about the last committed log entry
• D. The system halts entirely to avoid split-brain: no partition can proceed without all 5 nodes

Answer: (B)

Three nodes constitute a majority of a 5-node cluster. When their election timeouts expire without hearing from the leader, one becomes a candidate and wins an election by receiving votes from the other two — meeting the quorum requirement of 3 out of 5. The two-node partition cannot elect a leader (only 2 votes, need 3) and cannot commit new entries. Raft is designed so the majority partition continues operating safely while the minority stalls, preventing split-brain.

Question 2

In Raft, what mechanism guarantees that a committed log entry will never be lost, even after multiple leader failures?

• A. Committed entries are immediately written to durable storage on all nodes before the leader acknowledges them
• B. The leader keeps a backup copy of all committed entries and transfers them to new leaders upon election
• C. A candidate can only win an election if its log is at least as up-to-date as a majority of nodes, and committed entries are by definition on a majority of logs
• D. Followers reject any leader whose log does not contain all previously committed entries

Answer: (C)

An entry is committed only after a majority of nodes have written it. Raft's election safety property requires a candidate to have a log at least as up-to-date as a majority of voters to win — meaning any elected leader must have all committed entries. Option A is too strong: Raft requires majority acknowledgment, not all-node acknowledgment. Option D is close but incorrect: followers accept leadership based on the log-currency comparison in the vote request, not by independently checking a list of committed entries.

Question 3

In Raft, a candidate can only win an election if its log is at least as up-to-date as the logs of a majority of nodes in the cluster.

• T. True
• F. False

Answer: True

This is Raft's election safety condition. When a candidate requests votes, each voter compares the candidate's last log entry (term and index) against its own. A node only votes for a candidate whose log is at least as current. Because any committed entry is on a majority of logs, and any winning candidate must receive votes from a majority, the winning candidate is guaranteed to have all committed entries — ensuring no committed entry is ever lost across leader changes.

Question 4

In Raft, any node can accept client write requests and replicate them to the rest of the cluster.

• T. True
• F. False

Answer: False

Raft's strong-leader design means only the current leader accepts client requests. If a client contacts a follower, the follower redirects to the leader. This constraint is fundamental to Raft's simplicity: funneling all writes through a single leader ensures data flows in one direction (leader to followers), eliminating the need for complex protocols to reconcile concurrent writes from multiple nodes.

Question 5

Why do Raft nodes use randomized election timeouts instead of a single fixed timeout value shared by all nodes?

Model answer: If all nodes had identical timeouts, they would all time out simultaneously when the leader fails, all become candidates at the same time, and split the vote — each node voting for itself with no candidate reaching a majority. Randomized timeouts ensure that, most of the time, exactly one node times out first and starts an election before others have timed out, allowing it to collect votes from nodes still in the follower state and win cleanly.

The randomized timeout is the key trick that makes Raft's leader election practical without a separate coordination mechanism. Split votes can still occur occasionally (if two nodes time out nearly simultaneously), but Raft handles this by incrementing the term and starting a new election after another randomized timeout — with high probability, one candidate wins quickly.