Emergency alerts should be published once while many departmental systems process them asynchronously. Which topic mechanism does that describe?
Select an answer to reveal the explanation.
Short Explanation
Pub/sub is the city PA system: say it once, and every department radio can pick it up on its own time. No need to call each desk in sequence.
Full Explanation
Emergency alerts published once while many departmental systems process them asynchronously describe publish/subscribe via Kafka topics: publish once, many subscribers process independently. That decouples the alert originator from the full fan-out list. Strict point-to-point RPC that blocks until every department replies couples latency and failure domains across the city. Manual email forwards as the only distribution path are slow and unauditable at scale. A write-once database row that no subscriber may read is not distribution. Exam caveat: critical alerts still need delivery monitoring, dead-letter handling, and clear retention so late-joining consumers can catch up within policy. Operational check: publish a drill alert once, confirm multiple department consumers process it, and measure that the publisher is not blocked on consumer completion. In production terms for publish/subscribe emergency fan-out, 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 publish/subscribe emergency fan-out after material dependency upgrades so regressions are caught before the next public release.