---
title: "Kafka eager vs cooperative rebalancing (cooperative-sticky)"
description: "A join under the range assignor revokes every partition. Under cooperative-sticky (KIP-429) only p1 moves while the rest of the Kafka group keeps consuming."
url: https://monedula.dev/kafka-simulator/scenarios/rebalance-protocols/
---

# Kafka eager vs cooperative rebalancing (cooperative-sticky)

Scenario 02.2.4 · Rebalance: eager vs cooperative. Consumer groups · Advanced · about 4 min · Apache Kafka 4.3.

A range group stops the world when a consumer joins; cooperative-sticky moves only what must move.

Run it: https://monedula.dev/kafka-simulator/playground/?scenario=02.2.4

## What you start with

Eager rebalancing (the classic protocol with an eager assignor such as range) revokes every assignment and stops the world when membership changes; cooperative-sticky rebalancing instead revokes only the partitions that must change owners. This scenario runs both on a consumer joining the same group.

## Step by step

1. **Range group ready** (t+0.000s): Two consumers, range assignor (classic protocol). 4 partitions split into contiguous blocks: c1 owns p0/p1, c2 owns p2/p3. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=02.2.4&t=0)
2. **Consuming, lag 0** (t+2.500s): One record per partition produced and consumed; committed offsets caught up to the high-watermark. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=02.2.4&t=1)
3. **Eager rebalance - stop-the-world** (t+3.150s): c3 joined. Every member revoked EVERY partition (range ⇒ eager). Nobody owns anything, so the in-window writes are not consumed and lag grows. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=02.2.4&t=2)
4. **Range reassigned** (t+3.300s): Assign phase: a full range recompute over 3 members - c1 p0/p1, c2 p2, c3 p3. Ownership restored; consumption resumes. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=02.2.4&t=3)
5. **Switched to cooperative-sticky** (t+5.900s): Assignor switched to cooperative-sticky: a real group stays on the classic protocol and now uses cooperative (KIP-429) rebalances, not the KIP-848 consumer protocol (the simulator's event log still tags it "consumer"). Same membership, so the distribution is unchanged - but the next join will be incremental. (Real consumers switch via a rolling restart.) [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=02.2.4&t=4)
6. **Cooperative rebalance - only the mover stops** (t+6.650s): c4 joined. Only the single moving partition (p1) is revoked/parked; p0, p2, p3 keep their owners and keep consuming. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=02.2.4&t=5)
7. **Cooperative assignment settled** (t+6.900s): The parked partition lands on c4. One partition each across the four members; the non-moving partitions never stopped. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=02.2.4&t=6)

## The takeaway

Cooperative-sticky rebalancing avoids the global stop-the-world pause - only the partitions actually being reassigned are revoked, so the rest of the group keeps consuming throughout the rebalance.

## Further reading

- [KIP-429 on the Apache Kafka wiki](https://cwiki.apache.org/confluence/display/KAFKA/KIP-429%3A+Kafka+Consumer+Incremental+Rebalance+Protocol)

## Troubleshooting

- [Kafka consumer group keeps rebalancing: causes and fixes](https://monedula.dev/kafka-simulator/troubleshooting/consumer-group-keeps-rebalancing/)