4.3 Static group membership — avoiding rebalance on restart
Default behavior: "the identity of a consumer as a member of its consumer group is transient. When consumers leave a consumer group, the partitions that were assigned to the consumer are revoked, and when it rejoins, it is assigned a new member ID and a new set of partitions through the rebalance protocol."
With group.instance.id set to a unique string → the consumer becomes a static member:
| DYNAMIC member restart | STATIC member restart | |
|---|---|---|
| Shut down | Leaves the group immediately → partitions REVOKED → REBALANCE | DOES NOT leave the group; remains a member until its session times out |
| Restart | New member ID → REBALANCE → new (different) partitions | Recognized by STATIC IDENTITY → REASSIGNED THE SAME PARTITIONS → NO REBALANCE (the coordinator just sends the cached assignment back) |
| Local state / cache | REBUILT | PRESERVED |
If two consumers join the same group with the same
group.instance.id, the second gets an error saying a consumer with this ID already exists.
When to use it — and the sharp trade-off
Use it when: "your application maintains local state or cache that is populated by the partitions assigned to each consumer. When re-creating this cache is time-consuming, you don't want this process to happen every time a consumer restarts."
⚠️ The cost — read this twice:
"On the flip side, it is important to remember that the partitions owned by each consumer will not get reassigned when a consumer is restarted. For a certain duration, no consumer will consume messages from these partitions, and when the consumer finally starts back up, it will lag behind the latest messages in these partitions. You should be confident that the consumer that owns these partitions will be able to catch up with the lag after the restart."
Tuning session.timeout.ms for static membership is a genuine dilemma:
Static members do NOT leave proactively on shutdown. Detecting when they are “really gone” depends ENTIRELY on session.timeout.ms.
- too LOW → rebalances trigger on a simple application restart (defeating the entire purpose of static membership)
- too HIGH → a genuinely dead consumer's partitions sit unconsumed for a long time → “large gaps in processing”
Set it high enough to survive a restart, low enough to allow automatic reassignment when there is more significant downtime.