Learn the vocabulary of a set of consumers sharing the work of reading a topic's partitions.
0 / 5 completed
1 / 5
At standup, a dev mentions a set of consumer instances that share the work of reading a topic's partitions, with each partition assigned to only one consumer within that set at a time. What is this set of consumers called?
A consumer group is a set of consumer instances that share the work of reading a topic's partitions, with Kafka assigning each partition to only one consumer within that group at a time, so the group as a whole processes the topic's full set of partitions in parallel without any partition being double-processed. A partition describes one of the topic's individual ordered logs, not the set of consumers reading them. This shared assignment is what lets a topic's total throughput scale by simply adding more consumers to the group, up to the number of partitions available.
2 / 5
During a design review, the team plans to add consumer instances to a group up to the number of partitions the topic has, since adding more consumers than partitions would leave some consumers with no partition assigned at all. Which capability does this reflect?
This reflects scaling consumer throughput by matching the number of consumers to the number of available partitions, since each partition can only be assigned to one consumer within the group at a time, meaning a consumer added beyond the partition count simply sits idle with nothing assigned. Assuming every added consumer always receives its own dedicated partition regardless of the topic's actual count misunderstands this hard ceiling on how far a single consumer group can scale. This is why the number of partitions a topic is created with directly caps how much parallelism a single consumer group can ever achieve for it.
3 / 5
In a code review, a dev notices a consumer instance restarting frequently due to a crash loop, and each restart triggers the whole consumer group to briefly pause while partitions are reassigned. What does this represent?
This is a consumer group rebalance triggered by a flapping consumer repeatedly joining and leaving the group, since Kafka has to reassign the affected partitions among the remaining, and then the returning, consumers every single time group membership changes. A hot partition problem is an unrelated concept about a partition key's distribution, not about consumer membership churn. Recognizing this rebalance-storm pattern in review matters because a flapping consumer can degrade the entire group's throughput, not just its own, every time it restarts.
4 / 5
An incident report shows message processing across the entire consumer group stalled repeatedly for several minutes at a time, because one consumer instance kept crash-looping and each restart triggered a full group rebalance. What practice would prevent this?
Fixing the root cause of the crash loop, combined with tuning rebalance-related settings such as a longer session timeout, addresses both why the flapping consumer keeps restarting and how sensitive the group is to a single consumer's brief absence. Leaving the crash-looping consumer running as-is is exactly what kept stalling the entire group's processing every time it restarted in this incident. This combination of root-cause fixing and rebalance tuning is the standard response once a flapping consumer has been identified as the source of repeated processing stalls.
5 / 5
During a PR review, a teammate asks why the team relies on a Kafka consumer group's automatic partition assignment instead of manually assigning specific partitions to specific consumer instances in configuration. What is the reasoning?
Manual partition assignment requires updating configuration by hand every time a consumer instance is added, removed, or fails, which doesn't scale well in a dynamic environment where instances come and go routinely. A consumer group automatically rebalances partitions across whichever consumers are currently healthy and present, adapting without any manual configuration change. The tradeoff is the brief processing pause that occurs during a rebalance itself, which manual assignment would avoid at the cost of requiring constant manual upkeep instead.