Static group membership in Kafka - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Static group membership with fixed member IDs

Given the following Kafka consumer group configuration with static membership, what will be the output when the consumer restarts with the same member ID?

Kafka

consumerProps.put("group.id", "my-group");
consumerProps.put("group.instance.id", "consumer-1");

// Consumer subscribes and polls messages
consumer.subscribe(Collections.singletonList("my-topic"));
ConsumerRecords<String, String> records = consumer.poll(Duration.ofSeconds(1));
System.out.println("Polled records count: " + records.count());

// Consumer closes and restarts with same group.instance.id
consumer.close();
consumer = new KafkaConsumer<>(consumerProps);
consumer.subscribe(Collections.singletonList("my-topic"));
records = consumer.poll(Duration.ofSeconds(1));
System.out.println("Polled records count after restart: " + records.count());

A

Polled records count: 0
Polled records count after restart: 10

B

Polled records count: 10
Polled records count after restart: 10

C

Polled records count: 10
Polled records count after restart: 0

D

Polled records count: 0
Polled records count after restart: 0

💡 Hint

Static group membership allows the consumer to keep its partition assignments across restarts, avoiding rebalance delays.

When a consumer uses static group membership with a fixed group.instance.id, Kafka recognizes it as the same member after restart. This prevents rebalancing and the consumer resumes from its last committed offsets. Therefore, after restart, it will not re-poll the same messages again, resulting in zero new records polled.

🧠 Conceptual

intermediate

Understanding static group membership benefits

Which of the following is a key benefit of using static group membership in Kafka consumer groups?

A It allows consumers to dynamically change their group.instance.id during runtime.

B It automatically increases the number of partitions in the topic.

C It eliminates the need for consumers to commit offsets manually.

D It reduces consumer group rebalances when a consumer restarts with the same member ID.

💡 Hint

Think about what happens when a consumer leaves and rejoins the group with the same ID.

Static group membership assigns a fixed member ID to a consumer. When the consumer restarts with the same ID, Kafka treats it as the same member, avoiding unnecessary rebalances and improving stability.

🔧 Debug

advanced

Debugging static group membership error

A Kafka consumer configured with static group membership fails to join the group and throws an error: "Member ID consumer-1 is already in use." What is the most likely cause?

A The consumer did not commit offsets before restarting.

B Two consumers are running simultaneously with the same group.instance.id.

C The topic has fewer partitions than consumers.

D The consumer group ID is missing in the configuration.

💡 Hint

Static group membership requires unique member IDs per active consumer.

Static group membership requires each active consumer to have a unique group.instance.id. If two consumers use the same ID at the same time, Kafka rejects the second with a member ID conflict error.

❓ Predict Output

advanced

Effect of static group membership on rebalance listeners

Consider a Kafka consumer with a RebalanceListener that logs partition assignments. The consumer uses static group membership and restarts with the same group.instance.id. What will the listener output after restart?

Kafka

consumerProps.put("group.id", "my-group");
consumerProps.put("group.instance.id", "consumer-42");

consumer.subscribe(Collections.singletonList("my-topic"), new ConsumerRebalanceListener() {
    public void onPartitionsRevoked(Collection<TopicPartition> partitions) {
        System.out.println("Partitions revoked: " + partitions);
    }
    public void onPartitionsAssigned(Collection<TopicPartition> partitions) {
        System.out.println("Partitions assigned: " + partitions);
    }
});

consumer.poll(Duration.ofSeconds(1));
consumer.close();

// Restart consumer with same group.instance.id
consumer = new KafkaConsumer<>(consumerProps);
consumer.subscribe(Collections.singletonList("my-topic"), new ConsumerRebalanceListener() {
    public void onPartitionsRevoked(Collection<TopicPartition> partitions) {
        System.out.println("Partitions revoked: " + partitions);
    }
    public void onPartitionsAssigned(Collection<TopicPartition> partitions) {
        System.out.println("Partitions assigned: " + partitions);
    }
});
consumer.poll(Duration.ofSeconds(1));

A

Partitions revoked: []
Partitions assigned: [my-topic-0, my-topic-1]

B

Partitions revoked: [my-topic-0, my-topic-1]
Partitions assigned: [my-topic-0, my-topic-1]

C

Partitions revoked: []
Partitions assigned: []

D No output from rebalance listener after restart

💡 Hint

Static membership avoids unnecessary rebalances on restart.

With static group membership, the consumer is recognized as the same member after restart. Kafka does not revoke partitions before restart and reassigns them immediately, so revoked partitions list is empty and assigned partitions are the same as before.

🧠 Conceptual

expert

Static group membership and offset retention

How does static group membership affect the retention of consumer group offsets in Kafka when a consumer leaves the group unexpectedly?

A Offsets are retained longer because Kafka waits for the static member to rejoin before removing offsets.

B Offsets are immediately deleted when the consumer leaves, regardless of static membership.

C Offsets are never deleted for static members, even if they never rejoin.

D Static group membership has no effect on offset retention policies.

💡 Hint

Think about how Kafka treats static members differently from dynamic members on unexpected leave.

Kafka retains offsets for static group members longer because it expects the member to rejoin with the same group.instance.id. This reduces unnecessary offset deletions and rebalances.