The GIS account publishes parcel-change events that the public-works work-order system must consume, but today's synchronous HTTP calls fail when work-order is patching, causing missed tickets. Which integration pattern should architects introduce?
Select an answer to reveal the explanation.
Short Explanation
If GIS has to wait on hold for work-order, a patch night loses tickets. SNS shouts the parcel change; SQS holds the line until work-order is ready. That's a mailbox, not a stare-down.
Full Explanation
When the GIS account publishes parcel-change events that the public-works work-order system must consume, but synchronous HTTP calls fail when work-order is patching and cause missed tickets, architects should publish parcel-change notifications with Amazon SNS and buffer work-order consumption with Amazon SQS so the systems are decoupled. That integration pattern preserves events across consumer downtime for municipal field work. Keeping synchronous HTTP and increasing GIS timeouts until work-order always answers fails because timeouts do not create a durable buffer during patches. Writing GIS events only to a shared Amazon S3 object that work-order overwrites each second as the bus fails fan-out, durability semantics, and concurrency. Requiring GIS to halt map edits whenever the work-order API is unavailable fails operational independence. Exam caveat: SNS+SQS decoupling beats longer synchronous timeouts. Operational check: publish SNS from GIS, subscribe SQS for work-order, set DLQs, process with visibility timeouts, test during planned work-order patches, and measure zero missed parcel tickets. 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.