A monolithic permitting application in a city account bundles citizen intake, card payments, and inspector workflow in one process, so a payment-vendor outage freezes new applications citywide. Which modernization opportunity should architects identify first?
Select an answer to reveal the explanation.
Short Explanation
When the cash register jams, the whole permit counter shouldn't close. Split intake, payments, and inspector workflow so one vendor hiccup doesn't take the city offline. A bigger box is still one box.
Full Explanation
A monolithic permitting application in a city account that bundles citizen intake, card payments, and inspector workflow in one process—so a payment-vendor outage freezes new applications citywide—should first identify decoupling as the modernization opportunity: separate intake API, payment, and workflow engines so each can scale and fail independently. That limits blast radius for residents filing permits when payments are degraded. Merging the remaining city websites into the same monolith to reduce the number of systems fails by increasing coupling and outage scope. Adding more threads inside the monolith and keeping a single deployment unit forever fails independence of failure domains. Moving the entire monolith onto a larger dedicated host in one Availability Zone fails resilience and does not address vendor-outage coupling. Exam caveat: modernization starts with decoupling failure domains, not bigger boxes or bigger monoliths. Operational check: define service boundaries, introduce async payment callbacks, deploy independently, run chaos tests for payment outage, and ensure intake can queue when payments are down. 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.