A consumer group has 12 consumers on a topic of 8 partitions, and lag still grows. 4 consumers are idle, and every few minutes the whole group pauses while it rebalances. Explain what is happening and how you would fix it.

Within a group, each partition goes to exactly one consumer, so 8 partitions keep at most 8 consumers busy; the other 4 wait. Adding consumers past the partition count adds nothing. The pauses are rebalances: a consumer that does not call poll() within max.poll.interval.ms is counted as failed, and its partitions are reassigned to the others, which stops their processing while the group settles. Fix the slow processing per poll (smaller batches with max.poll.records, or faster work), use a cooperative assignor so a rebalance moves only the partitions that change, and if one consumer per partition still cannot keep up, add partitions (planned, because keys move) rather than consumers.

1. Why 4 consumers are idle

Kafka tracks a group's progress as one offset per partition, which only works if one consumer owns each partition at a time. The parallelism of a group is therefore the partition count:

2. Why the group keeps pausing

The usual cause is processing that takes longer than max.poll.interval.ms (5 minutes by default) between polls: a large batch, a slow database call, a retry loop. The group coordinator decides the consumer has died and rebalances. The consumer then finishes, polls, rejoins, and the group rebalances again. Partitions that change owner are not processed until the rebalance completes.

3. The fixes, in order

1. Find where the time goes. kafka-consumer-groups.sh --describe --group my-group shows lag per partition and which consumer owns it. Lag on every partition means too little capacity; lag on one partition means a hot key.
2. Poll more often. Lower max.poll.records so each batch finishes well inside the interval, or raise max.poll.interval.ms if a batch is legitimately slow.
3. Rebalance less painfully. CooperativeStickyAssignor keeps as many existing assignments as possible and rebalances cooperatively, and a static group.instance.id with a longer session timeout lets a restarted consumer come back without a rebalance.
4. Then add partitions. If 8 consumers working flat out cannot keep up, the topic needs more partitions. Confluent's rule sizes them as the throughput divided by what one consumer reads from one partition. Plan it, because adding partitions remaps keys.

4. When lag is on one partition only

That is a hot key: one customer or one default value sending most of the traffic. More partitions do not help it, because a key always goes to one partition. Change the key, or split the hot key's work downstream.

What interviewers want: one consumer per partition per group, partitions as the ceiling on parallelism, rebalances caused by slow polls, cooperative rebalancing and static membership, reading lag per partition, and a hot key as the case more partitions cannot fix.