Building-permit review and fee-collection microservices must scale independently, keep each task until success or dead-letter, and avoid losing work if one side slows. Which Domain 3 service best fits that decoupling?
Select an answer to reveal the explanation.
Short Explanation
When two city desks must not drop a form between them, use a durable inbox. Queue keeps the task until delete, and a DLQ isolates poison messages. Always-on HTTP or a click firehose solves different problems.
Full Explanation
OCI Queue is the Domain 3 service that lets building-permit review and fee-collection microservices scale independently while keeping each task until success or dead-letter isolation. Producers publish work without blocking on the peer’s availability; consumers process when ready; visibility timeout hides in-flight work; and a dead-letter path isolates poison messages after max delivery attempts so failures do not silently vanish. That durable inbox is what prevents lost forms when one side slows.
API Gateway alone fails by concept: always-on HTTP couples request lifetime to the callee and does not provide a durable task inbox or DLQ for work that must survive consumer slowdowns. OCI Streaming alone fails the discrete-task story: Streaming’s append-only, offset-based log is built for replayable event firehoses, not for “keep this permit task until delete or DLQ” worker handoff. OCI Events alone fails because bucket-landing and resource rules are not a general microservice task bus for permit-to-fee work between two independently scaling apps.
Exam caveat: if the stem stresses independent scale plus durable tasks plus DLQ, Queue is the fit; Streaming and Events solve adjacent but different problems. Operational check: publish permit tasks while pausing the fee consumer, confirm channel depth retains work, resume the consumer, and verify successful deletes—then force max deliveries on a bad message and confirm it lands in the DLQ path.