Eager, cooperative and static membership

Key points

• The original eager protocol is stop-the-world: every member revokes every partition, then the whole group is reassigned. A group of fifty consumers stops completely because one restarted.
• Cooperative incremental rebalancing revokes only the partitions that actually need to move. The other members keep processing throughout, which is the difference between a blip and an outage on a large group.
• Cooperative takes two rounds by design: the first revokes what must move, the second assigns it. Seeing two rebalances in the log is correct behaviour, not a fault.
• Static membership goes further. With group.instance.id set, a member that restarts within session.timeout.ms reclaims its own partitions with no rebalance at all.
• That is what makes rolling restarts of a large group cheap - a pod restarting in twenty seconds never triggers a reassignment.
• The trade-off is real: a genuinely dead static member is not detected until its session times out, so its partitions sit unconsumed for that long. Static membership deliberately chooses slower failure detection in exchange for stable rolling restarts.

Example

# Cooperative rebalancing - the default assignor since Kafka 3.0.
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor

# Static membership - the id must be STABLE and UNIQUE per instance.
# In Kubernetes a StatefulSet ordinal is the natural source.
group.instance.id=order-consumer-3
session.timeout.ms=45000

---
# What one pod restart costs, under each protocol:
#
#   Eager        all 50 consumers stop, full reassignment      ~5-10s of nothing
#   Cooperative  only the moving partitions pause              the other 49 keep going
#   Static       nothing moves at all, if back within 45s      no interruption
#
# And what a genuine crash costs:
#
#   Eager/Cooperative  detected in ~session.timeout.ms, partitions reassigned
#   Static             SAME timeout, but nothing is reassigned until it expires -
#                      so those partitions are unconsumed for the full 45 seconds
#
# Choose static when restarts are frequent and planned. Avoid a long session
# timeout with static membership unless you can tolerate that gap.

Cooperative keeps the group working during a reassignment; static avoids the reassignment entirely, at the cost of slower failure detection.