A telemetry platform must ingest every change to several high-volume Dataverse tables, hundreds of events per second at peak, so that multiple analytics consumers can each read the stream independently at their own pace. Dataverse will post the events through a service endpoint. Which design fits best?

Azure Event Hubs is designed for high-throughput event streaming. Events are written to partitions and retained for a period, and each consumer group maintains its own read position, so several independent applications can read the full stream at their own pace without affecting one another. Dataverse can register an Event Hubs service endpoint and post the execution context for each step, and an Event Hubs-triggered function per consumer group scales across partitions. A single Service Bus queue delivers each message to one receiver; attaching several consumers makes them compete, so each analytics application sees only a fraction of the events rather than all of them. Fanning out through one HTTP-triggered function couples every consumer to that function's availability and latency, multiplies outbound calls, and loses events whenever a downstream consumer is slow or unavailable, because a webhook offers no retained stream for replay. Sessions on a Service Bus queue group related messages so they are processed in order by one receiver at a time; they partition work among competing consumers rather than giving each consumer its own complete copy. Exam caveat: Service Bus topics also support multiple subscribers and add features such as dead-lettering, which suit transactional processing better than high-volume telemetry. Operational check: verify that each consumer group's checkpoint advances independently and that throughput units or partitions cover peak load.