Raft Leader Election and Majority Voting
Raft leader election is the process by which a cluster chooses one server to coordinate replicated log writes. It uses numbered terms, randomized waiting periods, and majority votes so that only one leader can safely control a term, even when messages are delayed or servers fail.
The problem Raft must solve
Raft is used to replicate a sequence of commands across several servers. Each server stores a log, an ordered list of commands, and applies those commands to a state machine, the data-processing logic that turns commands into state changes. Replication lets the service continue when one server fails, but it creates a coordination problem: who is allowed to accept writes, and when is a write safe to report as successful?
Without an election rule, two servers might both believe they are in charge after a network interruption. Each could accept different commands at the same log position. If both announced success, replicas could permanently disagree about the operation order.
Raft makes a distinction between having an entry and committing it. An entry is committed only after Raft knows that it is stored on a majority of servers—the smallest number that is more than half the cluster. In a five-server cluster, a majority is three. A server may temporarily hold an uncommitted entry that is later discarded, but committed entries must survive leader changes.
Terms divide time into eras
A term is a monotonically increasing number that identifies an era of leadership. Servers include their current term in election and replication messages. A server that sees a higher term updates its own term and returns to the follower role, meaning it accepts coordination from another server rather than trying to lead.
Terms solve a key ambiguity. Suppose an old leader was disconnected from the rest of the cluster and a new leader was elected. When the old leader reconnects, its messages carry an older term. Other servers can reject those messages, so the old leader cannot resume authority merely because it was once leader.
A server usually persists its current term, the candidate it voted for in that term, and its log. Persisting these values means a crash and restart do not let the server vote twice in one term or forget which era its log belongs to.
How an election starts
Normally, a leader sends frequent heartbeats, empty replication messages that tell followers it is still alive. A follower starts an election when it has not heard a valid message from the leader before its election timeout, the maximum time it will wait before trying to become leader.
The timeout is randomized independently on each server. For example, servers might choose different delays from a configured range. This does not make the election safe by itself; it makes simultaneous elections unlikely. If every server waited exactly 300 milliseconds, they could all become candidates together whenever a leader failed, splitting the vote repeatedly.
A candidate performs four basic steps:
- It increments its term and changes to the candidate role.
- It votes for itself.
- It sends a vote request containing its term and information about its last log entry.
- It waits for votes, a newer-term message, or another valid leader.
Each server grants at most one vote in a term. It grants that vote only if it has not already voted for someone else and the candidate's log is at least as up to date as its own. “Up to date” means the candidate has a later final log term, or the same final term and at least as many entries. This check prevents a server with missing committed history from becoming leader.
The candidate becomes leader after receiving votes from a majority, including its own vote. In a five-server cluster, three votes are enough. If no candidate gets a majority—for example, because votes are split or the network is partitioned—the candidates wait for new randomized timeouts, start newer terms, and try again.
Randomized timeouts improve the chance that an election finishes quickly. Majority voting is what makes the result safe.
Why two leaders cannot safely coexist
A majority has an important mathematical property: any two majorities overlap in at least one server. In a five-server cluster, any two groups of three share a server.
Because a server casts at most one vote per term, two different candidates cannot both receive a majority in the same term. If a candidate receives a message from a higher term, it immediately steps down. Together, these rules prevent two valid leaders from operating in the same term.
A disconnected old leader may still believe it is leader. However, it cannot commit new entries because it cannot reach a majority. It might append entries to itself or to a small isolated group, but those entries are not yet committed. After reconnecting, it learns about the newer term and abandons leadership; a later leader may overwrite those uncommitted entries.
How election rules protect the log
Leadership alone is not enough. Raft also uses the log information in vote requests to preserve committed entries. A candidate cannot win votes from servers whose logs are more up to date unless it has a log at least as complete as theirs. Since a committed entry exists on a majority, any newly elected leader must have encountered at least one server that stored that entry. The leader therefore cannot safely replace committed history with a conflicting entry.
Once elected, the leader replicates client commands using append-entry messages. Each message identifies the log entry immediately before the new entries by its index and term. A follower rejects the message if that preceding entry does not match. The leader then retries with an earlier position until the logs agree, after which the follower can copy the leader's entries.
When the leader has replicated an entry to a majority, it marks the entry committed and tells followers. A command is then safe to apply to the state machine and report as successful. Conflicting entries that were present only on a minority are not considered successful and can be removed during this repair.
What the familiar log messages mean
Logs such as election timeout, became candidate, received majority, became leader, or stepping down for higher term describe this protocol directly. Repeated elections often indicate a failed leader, a timeout configured too aggressively, or a network that cannot reliably deliver messages. A server that repeatedly becomes candidate but never becomes leader is usually unable to obtain a majority—not evidence that several leaders are safely active.
Raft's design separates the jobs cleanly: terms identify which leadership era is current, randomized timeouts give one candidate a chance to get ahead, and majority votes provide the overlap that prevents competing leaders from committing conflicting histories.