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
Use the state-transition figure to trace follower, candidate, and leader changes during elections. section 10.6.3



