Every node in a Raft cluster starts as a follower: it does nothing but wait for heartbeats and reset a timer. That timer is the whole election. Here is the literal sequence, node by node.
currentTerm = 0 and arms an election timer with a duration sampled uniformly from 150–300ms (the classic randomization). The timer is monotonic — it runs even when the node is busy, because Raft uses the OS monotonic clock, not wall time.currentTerm to term N and casts its own vote. The vote is recorded as votedFor = self. A node may grant at most one vote per term, and this one is already spent — which is why a node can never vote for two candidates in the same term.RequestVote RPC to every peer in parallel: term=N, candidateId, lastLogIndex, lastLogTerm. In etcd's implementation this is one goroutine per peer with a 1s RPC timeout, so the whole fanout completes in roughly one network RTT (~0.5–5ms in a datacenter).lastLogTerm first, then lastLogIndex. This guarantees the winner's log is the most complete — a candidate missing committed entries can never be elected. The vote reply carries the peer's term; if that term is higher than the candidate's, the candidate steps back down to follower immediately.AppendEntries (heartbeats) to every follower immediately, then every 100ms (etcd default). Each heartbeat resets the followers' election timers. Election machinery freezes until the leader fails again — that's the steady state.A realistic term in pseudocode:
on election_timeout:
currentTerm += 1
votedFor = self
votes = 1
send RequestVote(term=currentTerm, lastLogIndex, lastLogTerm) to all peers
wait up to 1 RTT
if votes >= majority: become leader, broadcast heartbeats
else: back to follower, re-arm randomized timerThe cost story: a failover takes roughly one randomized timeout (150–300ms) plus one RTT for the vote round — sub-second in etcd's default 1s heartbeat / 2s timeout tuning. During that window the cluster is read-only: writes are rejected with ErrLeaderChanged-style errors because no leader's log is authoritative until the quorum exists.
The tradeoff that defines the design is between speed and safety: wide random timeouts make split elections rare but slow failover; strict log-freshness makes elections safe but occasionally blocks a well-connected candidate whose log is behind. That tradeoff, plus the one-vote-per-term rule, is what makes "at most one leader per term" a theorem instead of a hope.