A civic apps team debates where to put continuous click-stream telemetry versus reactions to OCI bucket and database state changes. Which distinction correctly separates Events from Streaming?
Select an answer to reveal the explanation.
Short Explanation
Events is for discrete OCI-emitted state changes you filter with rules. Streaming is the continuous bus you publish to, with partitions and replay. Click-streams belong on Streaming; bucket emits belong on Events—not the other way around.
Full Explanation
The civic apps team should separate the planes clearly: OCI Events filters discrete OCI-emitted resource-state changes with rules (and optional attributes/tags), then delivers matches to Functions, Notifications, or Streaming. OCI Streaming is a Kafka-compatible bus that your producers continually append to, with partitions, offsets, consumer groups, and replay within retention. Continuous click-stream telemetry belongs on Streaming; reactions to bucket and database state changes belong on Events. Claiming Events is a Kafka bus your producers continually append to, while Streaming only delivers OCI resource CRUD, reverses the products. Treating both services as identical and interchangeable for click-streams and bucket emits erases the producer distinction—application telemetry versus OCI-emitted CloudEvents—and leads to the wrong APIs and IAM. Saying Streaming replaces Events rules whenever Object Storage emit is enabled is false: enabling emit produces Events-compatible emissions that still need rules; Streaming does not become the filter engine. Exam caveat: you may still land an Events match onto Streaming when you want fan-out of a resource change, but that does not turn Events into a click-stream ingest path for browsers. Operational check: publish a synthetic click-stream record with the Streaming/Kafka API and separately trigger a create-object CloudEvent on an emit-enabled bucket; confirm only the latter matches an Events rule while the former appears only as stream records.