Raft leader election, step by step

Raft exists because Paxos is correct and unreadable. Leader election is the piece everyone sketches on a whiteboard and then gets subtly wrong in code.

Roles and terms

Each server is follower, candidate, or leader. Terms are logical clocks — a stale leader's writes must be rejected once a newer term has begun.

Election in one pass

timeline

Follower times out (no heartbeat from leader) → becomes **candidate**, increments term, votes for self.

Sends `RequestVote` RPCs to peers; needs a **majority** to win.

Winner becomes leader; sends heartbeats; followers accept append entries.

Loser or split vote → new election after randomized timeout.

Split votes aren't failure

If two candidates split the vote, no leader is chosen — and that's correct. Randomized election timeouts make another round likely to pick a single winner.

election.rs

1if self.state == State::Candidate && votes_received > quorum {2    self.state = State::Leader;3    self.send_heartbeats();4}

The mental model

Raft trades availability during partitions for understandability. You still need application-level conflict handling — consensus replicates an ordered log, not your business rules.

Where it shows up

etcd, TiKV, and countless homework implementations. NotiQ uses Postgres advisory locks for scheduler leadership — a different tool, same "one decider" shape. For membership before consensus, see SWIM gossip.