A 911 computer-aided dispatch feed on OCI Streaming must let several consumers process messages in parallel. What is the unit that determines that parallelism?
Select an answer to reveal the explanation.
Short Explanation
Partitions are like checkout lanes—more lanes mean more cashiers can work at once, but a seventh cashier with only six lanes stands idle. Messages spread across Oracle-managed partitions so consumers can read in parallel; fan-out scales with partition count. Partition count is chosen when you create the stream, not by raising a Function’s memory.
Full Explanation
Parallelism for consumers on OCI Streaming is governed by the stream’s partition count. Messages are distributed across Oracle-managed partitions so multiple consumers—especially in a consumer group—can process in parallel. Throughput and fan-out scale with how many partitions you created. Extra consumer instances beyond the partition count remain idle for assignment purposes because each partition is handled by one active group member at a time. For a 911 CAD feed that needs several consumers working concurrently, raise partition count at stream creation to match the intended parallelism.
Oracle Functions memory settings affect a function’s resources, not how many Streaming partitions exist or how group assignment works. API Gateway rate-limit policies apply to HTTP deployments, not as cursors on Streaming partitions. The number of Vault master keys on the stream pool does not create consumer parallelism.
Exam caveat: partition count is chosen when the stream is created and is not something you casually raise later like an autoscaler knob; plan throughput and fan-out up front.
Operational check: create a stream with a known partition count, start a consumer group with more members than partitions, and confirm only as many members as partitions receive assignments while the extras stay idle.