liveBook · Manning

Candidate

As explained in Kafka for Architects

Candidate state is the Raft election state in which a controller seeks votes to become the active controller.

Candidate state is the Raft election state a controller enters when it considers the leader controller unavailable and seeks votes to become the new leader. section 9.1.3

A follower controller reaches this state after exceeding controller.quorum.fetch.timeout.ms without a leader response. It requests votes from other controllers, including replicated metadata-log information. section 9.1.3 section 9.1.3

Election progress depends on three conditions:

  • Grant votes only when a controller has not voted in the current term and the candidate's log is at least as up-to-date. section 9.1.3
  • Recognize the candidate that secures a majority as the new leader controller. section 9.1.3
  • Synchronize previously committed metadata-log entries before the elected leader serves requests or manages updates. section 9.1.3

How Kafka for Architects covers it

How deep it goes
Details timeout detection, vote eligibility, majority selection, and post-election synchronization, but not Raft implementation internals.
Examples
Uses controller.quorum.fetch.timeout.ms, vote requests, replicated metadata logs, and controller.quorum.voters during leader failure.
What it assumes
Assumes controller roles, metadata logs, terms, and majority voting while explaining the election sequence through failure handling.
What you can do after
Evaluate controller failover behavior by tracing timeout detection, voting, majority formation, and metadata synchronization.
How it connects
Connects Raft, leader election, metadata logs, controller quorum, and broker failover.
Cover of Kafka for Architects
liveBookmanning.com
Read Kafka for Architects on liveBook Get the book at manning.com

Related concepts

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