A clerk waits on “is this SKU in stock?” while a separate nightly job fans a fee schedule change out to six interested services. How should those two interactions be designed?
Select an answer to reveal the explanation.
Short Explanation
A clerk asking “in stock?” needs an answer now—like asking a librarian a yes/no. Broadcasting a fee change is more like posting a notice on a bulletin board so many readers can pick it up without holding the poster hostage.
Full Explanation
Interaction style should follow caller need. The clerk’s stock check cannot proceed without a definitive answer in the current conversation, so synchronous request/response is the right contract: ask, wait, decide. The nightly fee-schedule fan-out has many interested consumers and no single caller that must block until every subscriber finishes; asynchronous publication lets the publisher emit once while six services consume independently without holding the publisher hostage.
Making both interactions fully synchronous forces every subscriber to block the fee-schedule publisher, creating a fragile fan-out where one slow consumer delays the whole release. Making the stock check fire-and-forget and expecting the clerk to poll email removes the answer from the interaction that needs it and invents an unreliable side channel. Merging both into one shared database trigger erases service-to-service contracts and recreates hidden coupling through schema and trigger side effects.
Exam caveat: choosing sync versus async is a design decision about coupling and latency; OCI Queue, Streaming, or Events are later implementation vehicles, not the reason to pick the pattern. Operational check: measure stock-check latency under load to keep the synchronous path within clerk UX budgets, and confirm fee-schedule consumers can lag and catch up without blocking the publisher’s commit.