Cooperative vs eager rebalancing in Kafka - Performance Comparison

Time Complexity: Cooperative vs eager rebalancing

O(n)

Understanding Time Complexity

When Kafka consumers rebalance, the way partitions are reassigned affects how long the process takes.

We want to understand how the time to rebalance grows as the number of consumers and partitions increases.

Scenario Under Consideration

Analyze the time complexity of these simplified rebalance steps.

// Eager rebalance example
onRebalance() {
  revokeAllPartitions();  // revoke all partitions from this consumer
  assignPartitions();    // assign partitions to this consumer
}

// Cooperative rebalance example
onRebalance() {
  revokePartitionsIncrementally();  // revoke partitions gradually
  assignPartitionsIncrementally();  // assign partitions gradually
}
    

This code shows two ways Kafka rebalances partitions among consumers: all at once (eager) or step-by-step (cooperative).

Identify Repeating Operations

Look at what repeats during rebalance.

• Primary operation: Reassigning partitions to consumers.
• How many times: For eager, all partitions are revoked and reassigned in one big step. For cooperative, partitions are revoked and assigned in smaller batches over multiple steps.

How Execution Grows With Input

As the number of partitions and consumers grows, the work to rebalance changes.

Input Size (partitions)	Approx. Operations (eager)	Approx. Operations (cooperative)
10	~10 revoke + 10 assign = 20	~10 revoke + 10 assign in steps = 20
100	~100 revoke + 100 assign = 200	~100 revoke + 100 assign in smaller steps = 200
1000	~1000 revoke + 1000 assign = 2000	~1000 revoke + 1000 assign in smaller steps = 2000

Pattern observation: Both methods do similar total work, but cooperative spreads it out, avoiding big pauses.

Final Time Complexity

Time Complexity: O(n)

This means the time to rebalance grows linearly with the number of partitions involved.

Common Mistake

[X] Wrong: "Cooperative rebalancing is slower because it does more steps."

[OK] Correct: Cooperative rebalancing spreads work over time but does not increase total operations; it reduces pause time and improves smoothness.

Interview Connect

Understanding how Kafka rebalancing scales helps you explain system behavior and design choices clearly, a valuable skill in many real-world roles.

Self-Check

"What if the number of consumers grows faster than partitions? How would that affect the rebalance time complexity?"

Practice

1. What is the main advantage of cooperative rebalancing in Kafka consumer groups?

easy

A. It reduces consumer pause time by reassigning partitions gradually.

B. It reassigns all partitions at once for faster processing.

C. It eliminates the need for consumer group coordination.

D. It increases the number of partitions automatically.

Solution

1. Step 1: Understand cooperative rebalancing behavior

   Cooperative rebalancing allows consumers to leave partitions gradually, which reduces the pause time during rebalancing.

2. Step 2: Compare with eager rebalancing

   Eager rebalancing reassigns all partitions at once, causing longer pauses, unlike cooperative rebalancing.

3. Final Answer:

   It reduces consumer pause time by reassigning partitions gradually. -> Option A

4. Quick Check:

   Cooperative rebalancing = gradual partition reassignment [OK]

Hint: Cooperative means gradual, eager means all at once [OK]

Common Mistakes:

• Confusing eager with cooperative rebalancing
• Thinking cooperative rebalancing eliminates coordination
• Assuming rebalancing increases partitions

2. Which configuration property enables cooperative rebalancing in Kafka consumers?

easy

A. group.rebalance.strategy = 'eager'

B. rebalance.policy = 'cooperative'

C. enable.cooperative.rebalance = true

D. partition.assignment.strategy = 'org.apache.kafka.clients.consumer.CooperativeStickyAssignor'

Solution

1. Step 1: Identify the correct property for assignment strategy

   Kafka uses partition.assignment.strategy to set the rebalance strategy class.

2. Step 2: Recognize the cooperative assignor class

   The cooperative rebalancing strategy is implemented by org.apache.kafka.clients.consumer.CooperativeStickyAssignor.

3. Final Answer:

   partition.assignment.strategy = 'org.apache.kafka.clients.consumer.CooperativeStickyAssignor' -> Option D

4. Quick Check:

   Cooperative assignor class = partition.assignment.strategy = 'org.apache.kafka.clients.consumer.CooperativeStickyAssignor' [OK]

Hint: Look for 'partition.assignment.strategy' with cooperative class [OK]

Common Mistakes:

• Using incorrect property names
• Confusing eager and cooperative strategy names
• Assuming a boolean flag enables cooperative rebalancing

3. Given two consumers in a group using eager rebalancing, what happens when one consumer leaves?

medium

A. All partitions in the group are reassigned immediately, causing a pause.

B. Only the partitions of the leaving consumer are reassigned gradually.

C. The remaining consumer continues without any rebalancing.

D. Partitions are reassigned only after a timeout period.

Solution

1. Step 1: Understand eager rebalancing behavior on consumer leave

   In eager rebalancing, when any consumer leaves, all partitions are reassigned immediately to maintain balance.

2. Step 2: Recognize the impact on consumer pause

   This immediate reassignment causes a pause for all consumers during the rebalance.

3. Final Answer:

   All partitions in the group are reassigned immediately, causing a pause. -> Option A

4. Quick Check:

   Eager rebalancing = full immediate reassignment [OK]

Hint: Eager means all partitions reassign at once [OK]

Common Mistakes:

• Thinking only leaving consumer's partitions reassign
• Assuming no pause occurs
• Believing reassignment waits for timeout

4. You have a Kafka consumer group using cooperative rebalancing but notice long pauses during rebalances. What is a likely cause?

medium

A. Partitions are being reassigned gradually as expected.

B. The consumer group has only one consumer.

C. Consumers are using the eager assignor instead of cooperative assignor.

D. The rebalance timeout is set too low.

Solution

1. Step 1: Check the assignor configuration

   If long pauses occur despite expecting cooperative rebalancing, the consumers might be using the eager assignor by mistake.

2. Step 2: Understand the impact of eager assignor

   Eager assignor causes all partitions to reassign at once, leading to longer pauses.

3. Final Answer:

   Consumers are using the eager assignor instead of cooperative assignor. -> Option C

4. Quick Check:

   Long pauses + cooperative expected = eager assignor used [OK]

Hint: Long pauses mean eager assignor, not cooperative [OK]

Common Mistakes:

• Assuming gradual reassignment causes long pauses
• Ignoring assignor configuration
• Blaming rebalance timeout without checking assignor

5. You want to minimize downtime in a Kafka consumer group with frequent consumer joins and leaves. Which strategy and configuration should you choose?

hard

A. Use eager rebalancing with default assignor for simplicity.

B. Use cooperative rebalancing with CooperativeStickyAssignor to reduce pause time.

C. Disable rebalancing to avoid any pauses.

D. Use eager rebalancing but increase session timeout to reduce rebalances.

Solution

1. Step 1: Identify the goal

   The goal is to minimize downtime during frequent consumer group changes.

2. Step 2: Choose the appropriate rebalance strategy

   Cooperative rebalancing reduces pause time by reassigning partitions gradually, which suits frequent joins/leaves.

3. Step 3: Select the correct configuration

   Using CooperativeStickyAssignor enables cooperative rebalancing in Kafka consumers.

4. Final Answer:

   Use cooperative rebalancing with CooperativeStickyAssignor to reduce pause time. -> Option B

5. Quick Check:

   Minimize downtime = cooperative rebalancing + correct assignor [OK]

Hint: CooperativeStickyAssignor minimizes downtime with frequent changes [OK]

Common Mistakes:

• Choosing eager rebalancing for low downtime
• Disabling rebalancing causing stale assignments
• Misconfiguring session timeout instead of strategy