liveBook · Manning

Leader election

As explained in Think Distributed Systems

A Raft protocol that elects a leader for a term and starts a new election when the current leader is suspected to have failed.

Leader election is the Raft process that chooses one active leader for a term and starts another election when the current leader is suspected to have failed. Each term begins with leader election, then delegates replicated-log management to the elected leader. section 10.6.2 section 10.6.3

Follow the election through three node states:

  • Follower: listens for leader messages and resets a randomly timed election timer whenever a message arrives. section 10.6.3
  • Candidate: increments its term, votes for itself, and sends RequestVote requests to the other nodes. section 10.6.3
  • Leader: begins serving as the term’s authority after receiving votes from a quorum, including its own vote. section 10.6.2 section 10.6.3

A suspected failure

Suppose a follower’s election timer expires because it has not received a leader message. It becomes a candidate and requests votes. A quorum makes it leader; a split vote causes another election, while learning of a newer term or leader returns it to follower status. section 10.6.3

Terms act as fencing tokens: nodes reject messages from lower terms. Thus, two nodes may believe they are leaders, but only the node with the current term may act as leader. Candidates must also have the most up-to-date logs, protecting log consistency and state machine safety. section 10.6.2 section 10.6.1

Figure 10.5 Node states and state transition of the Leader Election protocol
A diagram of a candidate

AI-generated content may be incorrect.

Use the state-transition figure to trace follower, candidate, and leader changes during elections. section 10.6.3

How Think Distributed Systems covers it

How deep it goes
Explains terms, node states, timers, voting outcomes, demotion, log freshness, and fencing, without detailing message-format or implementation internals.
Examples
Uses election timers, RequestVote requests, quorum and split-vote outcomes, term fencing, and follower-candidate-leader state diagrams.
What it assumes
Assumes familiarity with Raft nodes and clusters while introducing follower, candidate, leader, terms, quorum, and election timers.
What you can do after
Evaluate/understand how Raft selects a leader, retries split elections, rejects stale leadership, and protects committed state.
How it connects
Connects Raft leader election to terms, quorum, RequestVote, log replication, state machine replication, and state machine safety.

Also explained in

Compare how 4 books explain leader election →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Think Distributed Systems. The section links point to the parts of the book it draws on.