Consumer Group Fan-Out: Multiple Services Consuming the Same Events
Fast recall
Quick revision
Core answer
Understanding of Kafka consumer groups as the mechanism for event fan-out, and how it differs from point-to-point messaging
Confusing consumer groups with competing consumers — within a group, partitions are divided among consumers; across groups, all groups see all messages
Explain the offset per consumer group, contrast with RabbitMQ's competing consumer model, and discuss how to add a new consumer without affecting existing ones
Interview-ready guide
Interview answer
Kafka's consumer group model is what makes event-driven fan-out practical at scale.
- The key insight is that a Kafka topic is an append-only log, not a queue.
- Messages are not deleted when consumed — they are retained, and each consumer group maintains its own independent offset.
- So when an
OrderPlacedevent is published, the payment service, inventory service, and analytics service each consume it independently at their own pace.
How fan-out works:
- Each consumer group has its own offset pointer into the topic; analytics falling behind by 10,000 messages doesn't block the payment consumer or affect any other group
- Adding a new consumer group is operationally zero-impact — no producer changes, no effect on existing groups; the new group starts at whatever offset you choose, either latest for real-time or earliest to replay history
- One
OrderPlacedevent fans out to all groups without the producer knowing how many consumers exist
Load balancing within a group:
- Within a single consumer group, each partition is assigned to exactly one consumer; 12 partitions and 3 instances means each handles 4 partitions
- More instances than partitions means idle consumers — partition count is the parallelism ceiling and cannot be changed without rebalancing consumers
CooperativeStickyAssignordoes incremental reassignment during scaling events instead of pausing all partitions
Operational concerns:
- Rebalancing pauses processing — when pods scale or do rolling restarts, Kafka reassigns partitions; static membership with
group.instance.idprevents unnecessary rebalances during Kubernetes rolling restarts if pods reconnect withinsession.timeout.ms
I recommend sizing partition count at deployment time based on your expected maximum parallelism — changing partition count after consumers are live is operationally complex.
Consumer Group Fan-Out: Multiple Services Consuming the Same Events
Direct Answer
Kafka topics enable fan-out by allowing multiple consumer groups to independently consume every message. Each consumer group maintains its own offset, so 'OrderPlaced' events can simultaneously feed the payment service, inventory service, and analytics service—each at their own pace, with no coordination. A single consumer group provides competing consumers (load balancing) within one service.
Common Mistakes & Pitfalls
Confusing consumer groups with competing consumers — within a group, partitions are divided among consumers; across groups, all groups see all messages
Check your understanding
Answer these without looking back at the article.
- What happens to partition assignment when a consumer in a group crashes?
- How many partitions should a topic have, and how does it relate to consumer parallelism?
- How do you reset a consumer group offset to replay historical events?
Related interview prep categories
2Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.