What is static membership in Kafka consumer groups, and which config enables it?

## The problem static membership solves A Kafka **consumer group** is a set of consumer processes that cooperatively read a topic's partitions; each partition is owned by exactly one member. The **group coordinator** (a broker) tracks membership and runs **rebalances** — the protocol that (re)assigns partitions to members. A rebalance is disruptive: members stop consuming, revoke their partitions, and wait for a new assignment ("stop-the-world"). By default, membership is **dynamic**: every time a consumer calls `poll()`/joins, the coordinator assigns it a fresh, ephemeral **member ID**. So if a consumer process restarts (deploy, crash, k8s pod reschedule), the coordinator sees the old member leave and a brand-new member join — triggering **two** rebalances (one on leave, one on join). For large groups this is costly and causes consumer lag spikes. ## What static membership does **KIP-345** (Apache Kafka 2.3) introduced **static membership**. You assign each consumer instance a stable identity via the consumer config: ``` group.instance.id=worker-3 ``` This value must be **unique per instance** and **persistent across restarts** (e.g. derived from a k8s StatefulSet ordinal or a fixed hostname). When a consumer with a `group.instance.id` joins, the coordinator records it as a **static member**. - On a **clean shutdown**, a static member does **not** send a `LeaveGroup` request (unlike a dynamic member), so the coordinator keeps its slot. - When the same instance **rejoins within `session.timeout.ms`**, the coordinator recognizes the id and **returns the same partition assignment** — no rebalance, no reassignment. - Only if the instance stays gone **longer than `session.timeout.ms`** does the coordinator expire it and rebalance. ## Key terms - **`group.instance.id`**: the static, unique identity string. Its presence is what makes a member static. - **`session.timeout.ms`**: how long the coordinator waits without a heartbeat before declaring a member dead. For static membership you typically **raise** this (e.g. from the default 45s) so transient restarts fit inside the window. - **Fencing**: if two live instances share the same `group.instance.id`, the broker keeps only one and rejects the other with `FencedInstanceIdException`. ## Why it matters Static membership turns a routine deploy of an N-instance consumer fleet from N stop-the-world rebalances into (ideally) **zero** rebalances, dramatically cutting consumer lag and processing pauses during rolling restarts.