Citizen permit-status pages currently call the intake API, which calls payments, which calls inspections, and any hop timeout shows unknown during peak filing days. Which event-driven modernization should architects recommend?
Select an answer to reveal the explanation.
Short Explanation
Asking five offices in a chain whether a permit is ready is a game of telephone. Let each office post events and keep a status board the website can read. One timeout in the chain shouldn't blank the whole page.
Full Explanation
Citizen permit-status pages that currently call the intake API, which calls payments, which calls inspections—any hop timeout showing unknown during peak filing days—should replace the synchronous multi-hop status calls with an event-driven status projection that each service updates independently. That event-driven modernization keeps status readable when a downstream hop is slow during peak civic filing. Adding more sequential HTTP hops so each new municipal system must be queried live fails by lengthening the fragile chain. Having the browser call every backend database with long-lived SQL from the citizen network fails security and architecture. Caching the entire permitting monolith in a single in-memory map on one EC2 host with no events fails consistency and HA. Exam caveat: event-driven status projections beat synchronous multi-hop status fans. Operational check: emit domain events from intake/payments/inspections, update a status store or read model, serve the citizen page from the projection, test peak-day timeouts, and retire live multi-hop orchestration from the status path. Document the decision in the municipal architecture decision record and re-verify controls after the first production wave so auditors see continuous improvement, not one-time tribal knowledge.