A city permit office wants new applications to publish a message so scanners and citizen notifiers react on their own schedules without waiting on one shared call stack. Which integration approach best fits that loosely coupled design?
Select an answer to reveal the explanation.
Short Explanation
Think of the permit submit like a town-square bell—ring once, and whoever cares shows up when they can. Publishing an event lets scanners and notifiers react on their own clocks without tying everything into one brittle call chain. That loose coupling is the whole point of event-driven integration.
Full Explanation
A city permit office that wants new applications to publish a message so scanners and citizen notifiers react on their own schedules without waiting on one shared call stack should publish a permit-submitted event so independent consumers process asynchronously. Event-driven integration loosens coupling and lets municipal systems scale and fail independently. Requiring every scanner to poll the permit database with a synchronous stored-procedure call on each submit keeps tight coupling and shared-database contention. Collapsing scanners and notifiers into one monolithic midnight batch job removes responsiveness and independent schedules. Forcing each mobile client to invoke every downstream system with a chained remote procedure before submit succeeds creates brittle, high-latency user paths. Exam caveat: asynchronous design needs delivery guarantees, idempotent consumers, and dead-letter handling—fire-and-forget without observability is not complete civic architecture. Operational check: emit a permit-submitted event from the application service, confirm scanners and notifiers consume independently, simulate a consumer outage without blocking submit, monitor lag and retries, and document the event contract in the municipal integration catalog.