Static group membership in Kafka - Commands & Configuration

Introduction

Static group membership in Kafka helps keep consumer group membership stable even if consumers disconnect temporarily. This avoids costly rebalances and improves performance by assigning fixed members to the group.

When you have consumers that may restart or disconnect briefly but want to keep their assigned partitions without triggering a rebalance.

When running stateful stream processing applications that need stable partition assignments to avoid state loss.

When you want to reduce the overhead of frequent consumer group rebalances in a high-availability setup.

When you want to assign specific consumers to fixed partitions for better control and predictability.

When you want to improve consumer group stability in environments with unstable network connections.

Config File - consumer.properties

consumer.properties

group.id=my-static-group
bootstrap.servers=localhost:9092
partition.assignment.strategy=org.apache.kafka.clients.consumer.RangeAssignor
static.group.instance.id=consumer-1
key.deserializer=org.apache.kafka.common.serialization.StringDeserializer
value.deserializer=org.apache.kafka.common.serialization.StringDeserializer
enable.auto.commit=false

group.id: Identifies the consumer group name.

bootstrap.servers: Kafka broker addresses to connect.

partition.assignment.strategy: Strategy to assign partitions to consumers.

static.group.instance.id: Unique static identifier for this consumer instance to enable static membership.

key.deserializer and value.deserializer: How to convert message bytes to strings.

enable.auto.commit: Disables automatic offset commits for manual control.

Commands

Starts a Kafka consumer with a static group instance ID to join the group with stable membership.

Terminal

kafka-console-consumer --bootstrap-server localhost:9092 --topic my-topic --group my-static-group --consumer-property static.group.instance.id=consumer-1 --from-beginning

Expected Output

Subscribed to topic(s): my-topic

[Consumer is ready and consuming messages from the beginning]

→

--group - Specifies the consumer group name.

→

--consumer-property static.group.instance.id=consumer-1 - Sets the static group instance ID for stable membership.

→

--from-beginning - Consumes messages from the start of the topic.

Shows the current state and partition assignments of the static consumer group.

Terminal

kafka-consumer-groups --bootstrap-server localhost:9092 --describe --group my-static-group

Expected Output

GROUP           TOPIC           PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG             CONSUMER-ID                                    HOST            CLIENT-ID

my-static-group my-topic       0          15              15              0               consumer-1-12345-67890-abcde                  /127.0.0.1      consumer-1

→

--describe - Displays detailed information about the consumer group.

→

--group - Specifies the consumer group to describe.

Starts a second static consumer with a different static group instance ID to join the same group without triggering a rebalance.

Terminal

kafka-console-consumer --bootstrap-server localhost:9092 --topic my-topic --group my-static-group --consumer-property static.group.instance.id=consumer-2 --from-beginning

Expected Output

Subscribed to topic(s): my-topic

[Second consumer is ready and consuming messages]

→

--consumer-property static.group.instance.id=consumer-2 - Unique static ID for the second consumer instance.

Verifies that both static consumers are part of the group with stable partition assignments.

Terminal

kafka-consumer-groups --bootstrap-server localhost:9092 --describe --group my-static-group

Expected Output

GROUP           TOPIC           PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG             CONSUMER-ID                                    HOST            CLIENT-ID

my-static-group my-topic       0          15              15              0               consumer-1-12345-67890-abcde                  /127.0.0.1      consumer-1

my-static-group my-topic       1          10              10              0               consumer-2-12345-67890-fghij                  /127.0.0.1      consumer-2

→

--describe - Shows detailed group membership.

Key Concept

If you remember nothing else from this pattern, remember: static group membership uses unique instance IDs to keep consumers assigned without triggering rebalances on temporary disconnects.

Common Mistakes

Not setting the static.group.instance.id property for each consumer instance.

Without this ID, Kafka treats consumers as dynamic members causing rebalances on disconnects.

Always set a unique static.group.instance.id for each consumer to enable static membership.

Using the same static.group.instance.id for multiple consumer instances.

This causes conflicts and unstable group membership.

Assign a unique static.group.instance.id to each consumer instance.

Not verifying group membership with kafka-consumer-groups after starting consumers.

You might miss issues with partition assignments or membership stability.

Use kafka-consumer-groups --describe to check group state and assignments.

Summary

Configure each Kafka consumer with a unique static.group.instance.id to enable static group membership.

Start consumers with the static ID to join the group without triggering rebalances on disconnects.

Use kafka-consumer-groups --describe to verify stable membership and partition assignments.

Practice

1.

What is the main purpose of using group.instance.id in Kafka consumer groups?

easy

A. To increase the number of partitions in a topic

B. To encrypt messages within the consumer group

C. To automatically commit offsets more frequently

D. To assign a stable identity to a consumer and enable static group membership

Solution

1. Step 1: Understand the role of group.instance.id

   This configuration assigns a unique and stable identity to a Kafka consumer within a group.

2. Step 2: Connect stable identity to static group membership

   With a stable identity, Kafka can avoid unnecessary rebalances when a consumer restarts briefly, improving stability.

3. Final Answer:

   To assign a stable identity to a consumer and enable static group membership -> Option D

4. Quick Check:

   Stable consumer identity = static group membership [OK]

Hint: Static membership means stable consumer ID to avoid rebalances [OK]

Common Mistakes:

• Confusing group.instance.id with partition count
• Thinking it controls offset commit frequency
• Assuming it encrypts messages

2.

Which of the following is the correct way to set group.instance.id in a Kafka consumer configuration?

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
// What is the correct line to set static membership?

easy

A. props.put("group.instance.id", "consumer-1");

B. props.put("group.id.instance", "consumer-1");

C. props.put("static.group.id", "consumer-1");

D. props.put("group.instance", "consumer-1");

Solution

1. Step 1: Recall the exact property name for static membership

   The correct property to set a static consumer ID is group.instance.id.

2. Step 2: Match the correct syntax in Java Properties

   Using props.put("group.instance.id", "consumer-1") correctly sets the static ID.

3. Final Answer:

   props.put("group.instance.id", "consumer-1"); -> Option A

4. Quick Check:

   Correct property name = group.instance.id [OK]

Hint: Remember exact property name: group.instance.id [OK]

Common Mistakes:

• Swapping words in the property name
• Using incomplete or incorrect property keys
• Confusing with group.id

3.

Consider this Kafka consumer group with static membership enabled using group.instance.id. If a consumer with group.instance.id = "consumer-1" disconnects briefly and reconnects, what happens?

medium

A. The consumer is removed permanently from the group

B. The group triggers a full rebalance and reassigns partitions

C. The consumer resumes without triggering a rebalance

D. The consumer must use a new group.instance.id to reconnect

Solution

1. Step 1: Understand static membership behavior on brief disconnect

   Static membership keeps the consumer identity stable, so brief disconnects do not cause rebalances.

2. Step 2: Identify the effect on partition assignment

   The consumer resumes with the same partitions without triggering a rebalance, improving latency and stability.

3. Final Answer:

   The consumer resumes without triggering a rebalance -> Option C

4. Quick Check:

   Static membership avoids rebalance on brief disconnect [OK]

Hint: Static ID lets consumer resume without rebalance [OK]

Common Mistakes:

• Assuming every disconnect triggers rebalance
• Thinking consumer is removed permanently
• Believing new ID is required on reconnect

4.

Given this Kafka consumer config snippet, identify the error preventing static group membership:

props.put("group.id", "my-group");
props.put("group.instance.id", "consumer-1");
props.put("session.timeout.ms", "10000");
// Missing property?

medium

A. Missing group.protocol.type set to consumer

B. Missing enable.auto.commit property

C. Missing partition.assignment.strategy for static membership

D. Missing client.id property

Solution

1. Step 1: Check required properties for static membership

   Static membership requires group.protocol.type to be set to consumer explicitly in some Kafka versions.

2. Step 2: Identify missing property in config

   The snippet lacks group.protocol.type, which can prevent static membership from working properly.

3. Final Answer:

   Missing group.protocol.type set to consumer -> Option A

4. Quick Check:

   Static membership needs group.protocol.type=consumer [OK]

Hint: Set group.protocol.type=consumer for static membership [OK]

Common Mistakes:

• Assuming auto commit affects static membership
• Confusing client.id with group.instance.id
• Ignoring group.protocol.type requirement

5.

You have a Kafka consumer group with 3 consumers using static membership via group.instance.id. One consumer crashes and restarts quickly with the same group.instance.id. What is the expected behavior and why is static membership important here?

hard

A. The group pauses all consumption until manual intervention

B. The group avoids a rebalance, so processing continues smoothly with minimal delay

C. The restarted consumer must use a new group.instance.id or it will be rejected

D. The group triggers a rebalance to reassign partitions to other consumers immediately

Solution

1. Step 1: Analyze static membership effect on consumer restart

   Static membership keeps the consumer identity stable, so a quick restart does not cause a rebalance.

2. Step 2: Understand impact on group processing

   Because no rebalance occurs, partition assignments remain unchanged, allowing smooth and low-latency processing.

3. Final Answer:

   The group avoids a rebalance, so processing continues smoothly with minimal delay -> Option B

4. Quick Check:

   Static membership prevents rebalance on quick restart [OK]

Hint: Static membership keeps group stable during quick restarts [OK]

Common Mistakes:

• Expecting rebalance on every consumer restart
• Thinking new ID is required after crash
• Assuming group pauses automatically