Controller broker in Kafka - Step-by-Step Execution

Process Flow - Controller broker

Start Kafka Cluster

↓

Elect Controller Broker

↓

Controller Broker Manages Cluster

↓

Monitor Broker States

↓

Handle Partition Leadership Changes

↓

Update Metadata for Brokers

↓

Detect Broker Failures

↓

Trigger Reassignments

↓

Continue Managing Until Controller Changes

The controller broker is elected when the Kafka cluster starts and manages cluster metadata, broker states, and partition leadership until a new controller is elected.

Execution Sample

Kafka

1. Start Kafka cluster
2. Elect controller broker
3. Controller monitors brokers
4. Handle leader changes
5. Update metadata
6. Detect failures and reassign

This sequence shows how the controller broker manages cluster state and broker leadership dynamically.

Process Table

Step	Action	Controller State	Cluster Metadata	Output
1	Start Kafka cluster	No controller	Empty	Cluster starts
2	Elect controller broker	Controller elected (Broker 1)	Empty	Controller ready
3	Controller monitors brokers	Active	Metadata updated with brokers	Monitoring brokers
4	Handle leader changes	Active	Partition leaders updated	Leaders assigned
5	Update metadata	Active	Metadata refreshed	Metadata broadcasted
6	Detect broker failure	Active	Metadata marks broker down	Trigger reassignment
7	Trigger reassignment	Active	Partition leadership reassigned	Cluster stable
8	Controller continues managing	Active	Metadata current	Waiting for events
9	Controller failure	Controller lost	Metadata frozen	New controller election triggered
10	New controller elected	Controller elected (Broker 2)	Metadata refreshed	Cluster managed again

💡 Controller failure triggers new election, restarting management cycle

Status Tracker

Variable	Start	After Step 2	After Step 5	After Step 7	After Step 9	After Step 10
Controller State	No controller	Controller elected (Broker 1)	Active	Active	Controller lost	Controller elected (Broker 2)
Cluster Metadata	Empty	Empty	Metadata refreshed	Partition leadership reassigned	Metadata frozen	Metadata refreshed
Broker Status	Unknown	Known	Known	Broker 3 down	Broker 3 down	Known

Key Moments - 3 Insights

Why does the controller broker change during cluster operation?

When the current controller fails or loses connection (see step 9 in execution_table), a new controller is elected to maintain cluster management.

How does the controller broker handle broker failures?

It detects failures (step 6), updates metadata to mark brokers down, and triggers partition leadership reassignment (step 7) to keep the cluster stable.

What happens to cluster metadata when the controller changes?

Metadata is frozen during controller loss (step 9) and refreshed by the new controller after election (step 10) to ensure accurate cluster state.

Visual Quiz - 3 Questions

Look at the execution_table, what is the controller state after step 5?

A No controller

B Controller elected (Broker 1)

C Active

D Controller lost

💡 Hint

Check the 'Controller State' column at step 5 in execution_table

At which step does the controller detect a broker failure?

A Step 4

B Step 6

C Step 8

D Step 10

💡 Hint

Look for 'Detect broker failure' action in execution_table

If the controller never fails, which step would NOT occur?

A Step 9: Controller failure

B Step 7: Trigger reassignment

C Step 4: Handle leader changes

D Step 5: Update metadata

💡 Hint

Refer to execution_table steps related to controller failure and election

Concept Snapshot

Controller broker manages Kafka cluster metadata and broker states.
It is elected at cluster start and handles leader changes and failures.
Detects broker failures and triggers partition reassignment.
If controller fails, a new one is elected to continue management.
Ensures cluster stability and metadata consistency.

Full Transcript

The controller broker in Kafka is elected when the cluster starts. It manages cluster metadata, monitors broker states, handles partition leadership changes, updates metadata, detects broker failures, and triggers reassignment of partitions. If the controller fails, a new controller is elected to maintain cluster stability. This process ensures the Kafka cluster runs smoothly by coordinating brokers and partition leadership dynamically.

Practice

1.

What is the main role of the controller broker in a Kafka cluster?

easy

A. Manage leader election and cluster metadata updates

B. Store all the messages permanently

C. Serve as a client to produce messages

D. Handle consumer group offsets only

Solution

1. Step 1: Understand controller broker responsibilities

   The controller broker is responsible for managing cluster-wide tasks such as leader election and metadata updates.

2. Step 2: Compare other options

   Storing messages, producing messages, and handling consumer offsets are roles of other brokers or clients, not the controller.

3. Final Answer:

   Manage leader election and cluster metadata updates -> Option A

4. Quick Check:

   Controller broker = leader election manager [OK]

Hint: Controller broker manages cluster tasks like leader election [OK]

Common Mistakes:

• Confusing controller with brokers that store data
• Thinking controller handles only consumer offsets
• Assuming controller is a client

2.

Which of the following is the correct way to identify the controller broker using Kafka's command line tool?

kafka-metadata-quorum.sh --bootstrap-server localhost:9092 status

easy

A. Find the broker with the lowest port number

B. Check the broker with the highest broker ID

C. Look for the LeaderId in the output

D. Look for the broker with the 'leader' role in the output

Solution

1. Step 1: Understand the command output

   The kafka-metadata-quorum.sh status tool shows metadata quorum details including LeaderId, which is the ID of the current controller broker.

2. Step 2: Identify controller in output

   The controller broker is identified by the LeaderId field, not by broker ID, port number, or generic leader role.

3. Final Answer:

   Look for the LeaderId in the output -> Option C

4. Quick Check:

   LeaderId = controller broker ID [OK]

Hint: LeaderId in metadata quorum status identifies controller [OK]

Common Mistakes:

• Assuming highest broker ID means controller
• Using port number to find controller
• Confusing generic leader role with LeaderId

3.

Given the following code snippet using Kafka AdminClient in Java, what will controllerId hold after execution?

AdminClient admin = AdminClient.create(props);
Node controller = admin.describeCluster().controller().get();
int controllerId = controller.id();
admin.close();

medium

A. The total number of brokers in the cluster

B. The topic partition count

C. The port number of the controller broker

D. The broker ID of the current controller broker

Solution

1. Step 1: Analyze AdminClient describeCluster method

   The describeCluster().controller() returns the current controller broker as a Node object.

2. Step 2: Understand Node.id()

   The id() method returns the broker ID of that Node, which is the controller broker's ID.

3. Final Answer:

   The broker ID of the current controller broker -> Option D

4. Quick Check:

   controller().id() = controller broker ID [OK]

Hint: controller().id() returns controller broker's ID [OK]

Common Mistakes:

• Confusing controller ID with number of brokers
• Thinking it returns port or partition count
• Ignoring the blocking get() call

4.

Consider this snippet to get the controller broker ID using Kafka AdminClient in Java:

AdminClient admin = AdminClient.create(props);
Node controller = admin.describeCluster().controller().get();
int controllerId = controller.id();
admin.close();

What is the likely cause if this code throws a java.util.concurrent.ExecutionException?

medium

A. The close() method was called too early

B. The AdminClient failed to connect to any broker

C. The id() method returns a string, not int

D. The controller() method does not exist

Solution

1. Step 1: Understand ExecutionException cause

   An ExecutionException usually wraps an error during the async call, often connection failure.

2. Step 2: Check AdminClient connectivity

   If AdminClient cannot connect to any broker, the get() call on controller() future will fail with this exception.

3. Final Answer:

   The AdminClient failed to connect to any broker -> Option B

4. Quick Check:

   ExecutionException = connection failure [OK]

Hint: ExecutionException often means connection problem [OK]

Common Mistakes:

• Thinking method does not exist causes ExecutionException
• Confusing return types of id() method
• Assuming close() causes this error

5.

You want to write a Kafka monitoring tool that automatically detects when the controller broker changes and logs the new controller's broker ID. Which approach is best?

1. Use AdminClient to poll describeCluster().controller() periodically.
2. Subscribe to Kafka internal topics to listen for controller changes.
3. Manually check broker logs for controller election messages.
4. Restart all brokers to force controller re-election and detect changes.

hard

A. Use AdminClient to poll describeCluster().controller() periodically

B. Subscribe to Kafka internal topics to listen for controller changes

C. Manually check broker logs for controller election messages

D. Restart all brokers to force controller re-election and detect changes

Solution

1. Step 1: Evaluate monitoring approaches

   Polling describeCluster().controller() via AdminClient is a reliable, programmatic way to detect controller changes.

2. Step 2: Assess other options

   Subscribing to internal topics is complex and not guaranteed; checking logs is manual and slow; restarting brokers is disruptive and impractical.

3. Final Answer:

   Use AdminClient to poll describeCluster().controller() periodically -> Option A

4. Quick Check:

   Polling controller() is best for monitoring [OK]

Hint: Poll controller() with AdminClient for changes [OK]

Common Mistakes:

• Trying to read internal topics for controller changes
• Relying on manual log inspection
• Restarting brokers unnecessarily