A municipal transit dashboard has many producers continually appending vehicle telemetry, and several independent analytics consumers must read—and sometimes replay—the same data with per-partition order and Kafka-shaped clients. Which OCI service should carry that bus?
Select an answer to reveal the explanation.
Short Explanation
When many writers keep appending and many readers need the same ordered history (with replay), you want a stream—not a one-and-done work inbox. Streaming is the Kafka-shaped bus; Queue is for units of work that disappear after success; Events is for OCI’s own resource-state messages.
Full Explanation
Municipal transit telemetry with continual appends from many producers, multiple independent analytics consumers, per-partition order, and Kafka-shaped clients maps to OCI Streaming. Streaming is a managed, Kafka-compatible bus: producers append high-volume sequential data, consumer groups track offsets independently, and readers can rewind within retention to replay the same ordered history—exactly what a city dashboard and several analytics teams need from one shared telemetry feed. OCI Queue is the wrong shape because it is a transactional work inbox: after successful consume-and-delete, the message leaves the queue for other workers, which breaks multi-consumer replay of the same telemetry row. OCI Events exists for discrete OCI-emitted resource lifecycle CloudEvents filtered by rules; vehicle GPS appends are application data you publish yourself, not compartment resource CRUD. Oracle Functions is compute that runs code when invoked; it is not a durable messaging bus that stores, partitions, and fans out telemetry for independent readers. Exam caveat: Streaming retention and partition count are chosen at create time (and retention windows are measured in hours within documented bounds), so capacity planning must match how far back municipal analytics need to rewind. Operational check: confirm producers use the Kafka or Streaming API against the correct stream OCID and compartment, then validate that two consumer groups can read the same partitions at different offsets without interfering—proof that replay and multi-reader semantics are in play.