How Raft Leader Elections Work
Raft leader election is the process by which a cluster of servers chooses one server to coordinate replicated state changes. It uses numbered terms, randomized election timeouts, and majority voting so that a temporary failure or network delay does not produce two accepted leaders.
The problem an election solves
A Raft cluster usually has one leader: the server that accepts client commands and proposes their order to the other servers. The remaining servers are followers. If the leader crashes or becomes unreachable, the followers must choose a replacement.
Without an election protocol, several servers might independently decide that they are in charge. They could accept conflicting writes, and different parts of the cluster could believe different histories. Raft therefore needs both a way to detect that leadership has probably failed and rules that make leadership exclusive.
You may have seen these ideas in logs such as became candidate, requesting votes, or elected leader, or in configuration involving an election timeout.
Terms provide an ordering of authority
A term is a monotonically increasing number that labels a period of leadership or an election attempt. It is not a duration measured in seconds; it is a logical version number shared by the servers.
Each server stores its latest known term. When a server receives a message carrying a higher term, it updates its term and becomes a follower. A message from an older term is stale and is rejected or ignored. This lets servers recognize that an old leader or candidate no longer has current authority, even if a delayed network packet arrives much later.
A term can end without producing a leader. For example, candidates might split the votes. The next election attempt starts in a higher term.
Followers start elections after silence
A follower expects the leader to send regular heartbeats, which are ordinary Raft messages that contain no new client data but demonstrate that the leader is still active. The follower resets its election timer whenever it receives a valid message from the current leader or grants a vote.
If that timer expires without hearing from a leader, the follower assumes the leader has failed or is unreachable. It then:
- Increments its term.
- Changes its role from follower to candidate.
- Votes for itself.
- Sends a RequestVote message to the other servers.
The election timeout is randomized within a configured range. For example, servers might choose different delays from the same interval rather than all waiting exactly 500 milliseconds.
This randomness matters because identical timeouts would often make several followers become candidates at once. With different timeouts, one follower usually starts first and sends vote requests before the others time out. That candidate has a better chance of collecting a majority immediately.
The timeout should also be substantially longer than the heartbeat interval. Otherwise, normal scheduling delays could look like a failed leader.
What a vote request contains
A RequestVote message includes the candidate's term, its identity, and information about the candidate's replicated log, including the index and term of its last entry.
A receiver rejects a request with an older term. For a request in the receiver's current term, it grants its vote only if both conditions hold:
- It has not already voted for another candidate in that term. A server may vote for itself, or for one other candidate, but not both.
- The candidate's log is at least as up to date as the receiver's log. Raft compares the last-entry terms first; if those are equal, the longer log wins.
The log check prevents a candidate that is missing committed history from becoming leader. An election is not merely a popularity contest: the winner must also be eligible to preserve the replicated state.
A candidate becomes leader after receiving votes from a majority, meaning more than half of the cluster. In a five-server cluster, that is three votes. It then sends heartbeats, which tell the other servers that the election has finished and reset their election timers.
If a candidate receives a message from a leader with the same or a higher term, it returns to follower status. If it receives any message with a higher term, it first records that higher term and follows the rules for the new term.
Split votes and recovery
A split vote occurs when multiple candidates begin an election close together. Each may vote for itself and receive some additional votes, but none reaches a majority. The election then makes no leader.
Candidates wait for another randomized election timeout and try again in a new, higher term. Because the timeouts are random, one candidate will usually get a head start on the next attempt. Repeated collisions are possible, but increasingly unlikely; this is recovery through retry, not a special tie-breaking vote.
A candidate also abandons its attempt if it learns about a higher term or a valid leader. Thus, stale candidates do not continue campaigning after the cluster has moved on.
Why two leaders cannot both be accepted in one term
Raft's election-safety rule is built from two facts:
- Each server grants at most one vote per term. It records the candidate it voted for, so a delayed or duplicated request cannot make it vote again for a different candidate.
- Two majorities must overlap. In any cluster, two groups each containing more than half the servers share at least one server.
Suppose two candidates in the same term both claimed a majority. Their majorities would overlap at some server. That server would have had to vote for both candidates in the same term, violating the one-vote rule. Therefore two candidates cannot both be elected in one term.
This guarantee does not mean every server instantly agrees about the leader. Messages can be delayed, and an isolated old leader might temporarily continue acting as if it were in charge. But it cannot safely establish a second majority-backed leadership in its old term. Once it learns of a higher term, it steps down; and clients should rely on a leader's replicated, majority-confirmed work rather than on an isolated server's local belief.
Terms, voting restrictions, log freshness, and quorum intersection work together: timeouts trigger an attempt, votes choose a candidate, and the safety rules ensure that a successful election has one leader for that term.