A transit authority continuously publishes ridership pings, vehicle telemetry, and lifecycle events that several analytics services must read at their own pace in order. Which OCI service model fits this pattern?
Select an answer to reveal the explanation.
Short Explanation
Streaming is the city’s continuous event log—buses keep writing; many readers consume at their own pace without erasing the tape. A stream is a partitioned, append-only pub/sub log for continual sequential data such as activity, metrics, and lifecycle events. Queue is the one-shot job inbox; Events targets discrete resource-state changes—not the same tool.
Full Explanation
Continuous ridership pings, vehicle telemetry, and lifecycle events that many analytics services must read at their own pace belong on OCI Streaming. A stream is a partitioned, append-only log: producers publish, consumers read independently in a publish-subscribe model, and data remains available for the retention window so late or slow readers can catch up in order within a partition. That matches a transit authority’s ongoing sequential event firehose better than one-shot job queues or discrete cloud-event notifications.
OCI Queue as a one-shot job inbox that deletes on successful acknowledgment is a competing-consumer work queue, not a multi-reader historical log for telemetry. OCI Events targets discrete resource-state change notifications (for example an Object Storage event), not a continuous high-volume pub/sub log of vehicle pings. Using OCI Vault secrets as a pub/sub bus invents a messaging system Vault does not provide; Vault stores secrets, it does not stream telemetry.
Exam caveat: Streaming gives at-least-once delivery and per-partition order—not exactly-once global order. Design consumers accordingly.
Operational check: publish a short telemetry burst to a stream, start two independent consumers at different offsets or times within retention, and confirm both can read the same retained messages without one consumer deleting them for the other.