The Runtime Theory

Raft Leader Election: Terms, RequestVote, and the Majority Rule

Step through a Raft election — randomized timeouts, term increments, RequestVote RPCs, and the majority vote that produces exactly one leader per term.

The Runtime Theory Team07 stages

trace / request.md

ALL NODES FOLLOWA TIMER EXPIRESTERM INCREMENTEDREQUESTVOTE RPCSMAJORITY VOTESHEARTBEATSSTABILIZETERM N CONTINUES

readyEvery node starts as a follower, waiting for heartbeats from a leader. Each runs an election timeout randomized between 150–300ms — the randomness is what prevents simultaneous candidacies.

Election is what makes Raft work without coordination: a randomized timeout guarantees that only one node typically starts an election at a time. The candidate is self-nominating — it votes for itself, increments the term, and asks every peer to confirm it has the most complete log. A follower grants its vote only if it has not already voted this term and the candidate's log is at least as fresh as its own.

The majority is the whole point. No two candidates can both reach N/2+1 votes in the same term, so a winner is unique. The loser's votes are spent and can never be retracted within the term. Once elected, the leader's first job is immediate: heartbeats to every follower, resetting timers and freezing the election machinery until the next failure. The ordering — timeout, term, vote, heartbeat — guarantees at most one leader per term, which is the foundation every later Raft operation stands on.