All instances of a service share the same groupId — Kafka assigns each partition to exactly one consumer in the group. This means messages with the same key are always processed by the same instance, guaranteeing ordering per key. More partitions allow more concurrent consumers up to the partition count.

Consumer group scaling and manual offset management

Consumer group partition assignment rules:

1
Each partition is assigned to exactly one consumer in the group — no duplicate processing within a group.
2
More partitions = more consumers can work in parallel — set partition count at least equal to max instance count.
3
Same-key messages always route to the same partition and therefore the same consumer instance.
4
When an instance joins or leaves, Kafka rebalances partition assignments across the group.
5
Manual offset commits allow exactly-once semantics — commit after processing, not before.

Difficulty: 6/10

Topics: Kafka consumer groups, NestJS microservices, partition assignment guarantees

Scenario Questions

0-2 years experience

1
We need a new NestJS microservice that reads user‑signup events from a Kafka topic. How would you set up the consumer group and make sure each instance gets its own partitions?
2
If you run two instances of the same NestJS service with the same groupId against a topic that has three partitions, what will each instance receive?
3
Which NestJS configuration key controls the consumer group identifier when using the Kafka transport?

2-5 years experience

1
After a rolling restart, you notice some order‑created messages are processed twice. Explain how consumer group rebalancing could cause this and what you would change to prevent duplicates.
2
You scale a NestJS order‑processing service to five instances, but one partition ends up handling most of the load. What trade‑offs would you consider and how would you adjust the consumer configuration?
3
A partition stops being consumed after one of the NestJS consumers crashes. Walk me through how you would debug the rebalance and get the partition reassigned.

5-8 years experience

1
Design a strategy for exactly‑once processing of financial transactions in a NestJS app using Kafka consumer groups. Discuss idempotency, offset handling, and Kafka transaction APIs.
2
Your NestJS consumers are lagging at 10 k messages per second. Identify potential bottlenecks related to partition assignment and propose changes to the consumer group topology or NestJS settings to improve throughput.
3
Explain how you would implement graceful shutdown in a NestJS consumer group to commit offsets safely and avoid duplicate processing during a rolling deployment.

8+ years experience

1
Our platform is moving from a monolith to several NestJS microservices, each with its own Kafka consumer group. What architectural considerations around partition assignment, cross‑team ownership, and schema evolution would you raise?
2
Compare using a single large consumer group versus multiple independent groups for different business domains. How do scaling, operational overhead, and data isolation factor into the decision?
3
We plan to increase the number of partitions on a critical topic from 12 to 200 over the next year. Propose a long‑term strategy for monitoring and evolving partition‑assignment guarantees while keeping processing semantics consistent across teams.

Follow-up Questions

❓What happens to in‑flight messages if a consumer crashes during processing?
❓How would you guarantee ordering across multiple partitions if the business requires it?
❓Which metrics would you monitor to detect consumer lag or stalled partitions?