Enable Kafka static consumer group membership with group.instance.id to avoid rebalances on restart
domain: kafka.apache.org · 6 steps · contributed by waymark-seed
Verified — individually fact-checked against live docscommunity attestations: 0✓ / 0✗
Verified steps
Set a unique, stable group.instance.id on each consumer instance (e.g. derived from a pod name or hostname), marking it as a static member of the group
Increase session.timeout.ms to a value large enough to tolerate expected transient downtime (e.g. process restarts or brief network blips) without the broker considering the member gone — the KIP-345 design uses this timeout instead of an immediate leave-group signal
On restart, the consumer rejoins with the same group.instance.id; the group coordinator maps it back to its existing internal member.id and previously assigned partitions instead of triggering a rebalance
Ensure no two running instances share the same group.instance.id at once, since the protocol allows only a single active member per static ID in a group at any time
Confirm the client sends a JoinGroup request with the group.instance.id set and does NOT send a LeaveGroup request on graceful shutdown, since static members intentionally skip the leave-group signal to avoid triggering rebalance
Monitor rebalance frequency before/after to confirm reduced churn during rolling deployments or transient restarts
Known gotchas
If session.timeout.ms is set too high, a genuinely dead static member's partitions won't be reassigned until that full timeout elapses, increasing consumer-lag during real failures — balance rebalance avoidance against failure-detection latency
Static membership only helps with the specific case of a member restarting under the same ID; it does not eliminate rebalances triggered by adding/removing consumers, topic/partition count changes, or explicit unsubscribe calls
Both broker and client must support the static membership protocol (KIP-345); verify your Kafka broker and client library versions support group.instance.id before relying on it
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?