A Spark job and a separate audit service both read the same fare-tap topic without blocking each other. What Kafka role do those readers play?
Select an answer to reveal the explanation.
Short Explanation
Consumers are the listeners. Spark and audit can both tune into the same tap channel, each keeping its own place in the conversation.
Full Explanation
A Spark job and a separate audit service both reading the same fare-tap topic without blocking each other are consumers—optionally in different consumer groups—that independently process the same published taps. Each group tracks its own offsets. They are not producers writing new taps back onto gates, nor single brokers that delete messages after one read, nor mere topic names without runtime processes. Exam caveat: within one group, partitions are load-balanced; across groups, each group sees the full stream—know which pattern you need for analytics versus audit. Operational check: run two consumer groups on the fare-tap topic, verify both receive the same taps, and confirm one group’s lag does not stall the other. In production terms for Kafka consumers and consumer groups, 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 Kafka consumers and consumer groups after material dependency upgrades so regressions are caught before the next public release.