Overview
When group membership changes, the group coordinator triggers a rebalance. In the classic protocol the coordinator selects one member, the group leader, to compute the assignment. With an eager assignor (RangeAssignor, RoundRobinAssignor, StickyAssignor) every member revokes its entire assignment before taking part, so the group pauses. Cooperative rebalancing (CooperativeStickyAssignor, KIP-429, since Kafka 2.4) revokes only the partitions that have to move. Kafka's default assignor list is [RangeAssignor, CooperativeStickyAssignor], which behaves eagerly until RangeAssignor is removed from the list. Kafka 4.0 added a different protocol, KIP-848 (group.protocol=consumer), in which the broker computes the assignment; see the Kafka 4.x module.
Key configuration
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor — fully qualified class name; not used when group.protocol=consumer
group.instance.id=my-consumer-1 — static membership
session.timeout.ms=45000 — default: a client that sends no heartbeats within this time is removed from the group (classic protocol)Production tip
Check yourself
What is the main drawback of the classic (eager) rebalance protocol?
Sources
- ConsumerPartitionAssignor Javadoc (4.2) (opens in a new tab)
- KIP-429: Kafka Consumer Incremental Rebalance Protocol (opens in a new tab)
- KIP-345: Static membership protocol (opens in a new tab)
- Consumer configs (4.2 documentation) (opens in a new tab)
- Consumer rebalance protocol (4.2 documentation) (opens in a new tab)
Checked against Kafka 4.2 documentation on Oct 2026. Draft: not yet reviewed by a Kafka specialist. Releases move on, so confirm against the current documentation before you act on a number.