A public-works app must hand each repair ticket to exactly one worker, hide it while in flight, and remove it after success—with no need for a second team to replay yesterday’s tickets. Which OCI messaging choice fits?
Select an answer to reveal the explanation.
Short Explanation
One ticket, one worker, gone when done—that is a queue. A stream is a diary others can reread. If yesterday’s message must vanish after one success, pick Queue.
Full Explanation
OCI Queue matches the public-works pattern of one repair ticket, one worker, hide while processing, and delete on success. Queue delivers a discrete unit of work, applies visibility timeout so other consumers do not race the same ticket, and removes the message when the worker acknowledges completion. There is no requirement to keep yesterday’s tickets as a forever-replayable log when a second team only needs successful completion, not historical reread.
OCI Streaming fails this fit by concept: it keeps an append-only log so consumers can replay by offset. That durability model is excellent for click streams and multi-reader analytics, but it is the opposite of “vanish after one successful handoff.” OCI Events alone also fails: Events is a rule-and-action notification fabric for platform and resource changes, not a durable application work inbox that stores tickets until workers delete them. API Gateway caching fails for the same class of reason: caches retain responses for performance; they are not a work queue that hides in-flight units and deletes completed tickets after multi-day consumer replay.
Exam caveat: choose Queue when the story stresses at-most-once worker handoff and delete-on-success; choose Streaming when the story stresses replay and multiple independent readers of the same history. Operational check: publish one ticket to a Queue channel, GetMessages from a single worker, verify the message is invisible to a second consumer during visibility timeout, then delete and confirm it no longer reappears after the timeout.