How to use cooperative sticky assignor

There are two slightly different configuration paths depending on whether you are using the classic consumer group protocol or the newer consumer protocol introduced in Kafka 4.x.

For classic consumer groups, the main switch is partition.assignment.strategy. Kafka's 4.2 consumer config reference lists org.apache.kafka.clients.consumer.CooperativeStickyAssignor as a supported assignor for that property.

For the newer consumer protocol, the group is driven more from the server side. The client enables it with group.protocol=consumer, and can optionally request a specific server-side assignor with group.remote.assignor.

Use cooperative sticky assignor when you have long-running consumers, expensive warm-up, or frequent rolling deploys that make eager rebalances noisy and expensive.

The use case is not every consumer group by default. It helps most when the cost of revoking all partitions at once is materially worse than a more incremental reassignment strategy.

All members of the group need to be able to participate in the same rebalance protocol. Mixed assignment strategies or incomplete client upgrades can turn a rollout into more churn rather than less.

You also want to confirm that your consumer code handles incremental revocation and reassignment cleanly. The assignor reduces disruption, but it does not remove the need for correct offset commit and shutdown behavior.

If your deployment model supports stable identities, it also helps to set group.instance.id to something durable such as the hostname or the pod name from a StatefulSet in EKS. That gives Kafka a stable member identity across restarts and usually reduces unnecessary churn during rolling changes.

Kafka's consumer config docs and KIP-429 both describe a staged migration path for classic consumer groups. The important detail is that you do not jump straight from a purely eager assignor list to a purely cooperative one during a rolling deployment.

Kafka 4.2 explicitly says the default assignor list is RangeAssignor, CooperativeStickyAssignor, which is designed to make the upgrade path easier. KIP-429 goes further and describes the safe rollout as a two-bounce process.

Cooperative sticky assignor can reduce the blast radius of membership changes, but it does not make unhealthy groups healthy. If consumers are timing out because processing is too slow or max poll settings are wrong, the assignor cannot hide that forever.

It is best used as part of a cleaner rebalance strategy, not as a bandage for groups that are already unstable for other reasons.

Start with one or two candidate groups where rebalances are painful and client versions are under control. Change the assignor deliberately, deploy the group, and compare rebalance behavior before expanding to noisier fleets.

Track the metrics KIP-429 calls out around rebalance rate and latency, and pay attention to whether consumers now spend less time in disruptive full revocations.

If the group gets quieter and partition movement becomes more incremental, keep going. If duplicate processing or rebalance instability rises, stop and inspect client compatibility, partition.assignment.strategy, group.protocol, and consumer lifecycle behavior before rolling wider.