Constraints: the ChatOps Webex notifier must scale and release independently from the inventory UI; one small team owns a separate batch reporter with a single weekly change window. Which pairing of official patterns best matches?
Select an answer to reveal the explanation.
Short Explanation
Match the tool to the job: independent scale and release push you toward microservices or SOA; one team and one window point back to a monolith. Event-driven is extra when producers must not block—not a blanket stamp for every box.
Full Explanation
The pairing that best matches is microservices or coarser SOA for the independently scaled and released ChatOps Webex notifier versus inventory UI, and a monolith for the single-team weekly batch reporter. Match the tool to the job: independent scale and release push you toward microservices or SOA; one team and one change window point back to a monolith. Event-driven is an extra pattern when producers must not block—not a blanket stamp for every box in the municipal estate.
Forcing event-driven for every component including the weekly batch reporter adds broker complexity where a scheduled single-team job has no fan-out or non-blocking producer requirement. One global monolith for notifier, UI, and reporter because all are municipal apps ignores the stated independent scale and release need between notifier and UI. Replacing all four official application patterns with a graph database architecture answers a data-model question and abandons application-pattern selection entirely.
Exam caveat: “microservices or coarser SOA” for the notifier/UI split should still be sized to team boundaries—do not over-fragment a two-component split into dozens of services. Operational check: verify the notifier can deploy and autoscale on a different cadence from the inventory UI in staging, while the weekly reporter remains a single deployable owned by one team with its documented change window.