A city permitting portal must wake the intake service only when a payment clears, without a nightly batch job polling a database. Which application pattern should the developers implement?
Select an answer to reveal the explanation.
Short Explanation
Picture a doorbell instead of someone walking the hallway every hour checking if the package arrived. When payment clears, publish an event and let intake wake only then — no nightly database poll. That is the event-driven pattern the portal needs.
Full Explanation
In a city permitting portal, waking intake only when payment clears is a classic event-driven design problem. The correct approach is for the payment service to publish a payment-cleared domain event and for the intake service to react asynchronously. That pattern treats a cleared payment as a meaningful business fact: once published to a bus or queue (EventBridge, SNS, or SQS), consumers scale independently, stay idle when unpaid rows dominate the table, and avoid a nightly batch window that delays citizens who paid minutes ago. Event producers and consumers own separate failure domains, which is essential when permitting, treasury, and records teams deploy on different schedules.
A monolithic cron that scans every permit row each night fails by concept because it couples latency to the batch schedule, burns capacity on unpaid rows, and still requires polling semantics the scenario forbade. A tightly coupled HTTPS call from a payment-table trigger that waits for intake to finish adds synchronous coupling: payment latency becomes intake latency, timeouts cascade, and one slow intake path blocks treasury acknowledgements. A shared in-memory cache on one EC2 instance that both services poll every second fails operationally and architecturally—single-host state, busy-wait load, and no durable event history when that instance restarts.
Exam caveat: event-driven does not mean “fire and forget forever.” Municipal money paths still need idempotent consumers, dead-letter handling, and audit trails tying a payment event to a permit case ID. Choosing EventBridge versus SNS versus SQS is a delivery-shape detail; the tested idea is publish-and-react instead of poll-and-batch.
Operational check: emit a payment-cleared event with a stable payment and permit correlation ID, confirm intake processes only on that event (no nightly full-table scan in the runbook), verify consumers are idempotent under at-least-once delivery, and alert on DLQ depth so failed intakes never silently strand paid permits.