Real-time alerting workers should share the 311 topic load, while a separate audit pipeline must see every message on its own. How do consumer groups enable that?
Select an answer to reveal the explanation.
Short Explanation
Think of two book clubs sharing one library series: Club A splits the chapters among members, while Club B reads the whole series for notes. Consumer groups work the same way on a topic.
Full Explanation
Real-time alerting workers share the 311 topic load while a separate audit pipeline sees every message by using consumer groups: one group load-balances partitions across alerting workers; another group independently reads all messages for audit. That is the standard Kafka multi-subscriber pattern. Only one consumer in the entire city may ever read a topic is false. Producers need not duplicate every message into private databases manually for a second team. Brokers should not silently drop messages meant for a second team. Exam caveat: audit and alerting groups must each commit offsets correctly or one workload’s failure mode will be misunderstood as data loss. Operational check: deploy alerting consumers in group A and an audit consumer in group B, verify partitions split within A while B receives the full stream, and monitor lag per group. In production terms for multiple consumer groups for share versus audit, assign an owning team, wire a dashboard that shows the pattern is healthy under peak civic load, and require a staging drill that rehearses failure and recovery before resident impact. Revisit the choice when traffic shape, retention, or integrity needs change, and keep a named rollback owner on the change record. Re-test both the happy path and the failure path for multiple consumer groups for share versus audit after material dependency upgrades so regressions are caught before the next public release.