Service Bus vs Event Grid vs Event Hubs: One Sentence Each

Microsoft has three messaging services. Most teams use the wrong one for their use case at least once.

Service Bus — commands and workflows

"Do this thing."

• FIFO queues. Sessions for ordered processing per partition key. Dead-letter queues. Scheduled messages.
• Maximum message: 100 KB Standard / 1 MB Premium.
• Throughput: up to ~2,000 msg/sec/queue Standard, ~10x on Premium.
• Use for: workflow orchestration, command processing, order-pipeline stages, anything that needs at-least-once with ordering.

Event Grid — reactive notifications

"Hey, something happened."

• Push-based pub/sub. Sub-second latency. CloudEvents schema.
• Built-in handlers: Functions, Logic Apps, webhooks, queues, topics.
• Massive fan-out (millions of subscribers).
• Use for: "a blob was created", "a resource changed state", "deploy webhook fired". Event-driven control plane.

Event Hubs — high-throughput streams

"Here's a firehose."

• Append-only log. Partition-based. Replay supported (up to 7-90 days).
• Throughput: millions of events per second.
• Kafka API compatible (use kafka clients directly).
• Use for: telemetry ingestion, log aggregation, click streams, IoT ingest.

The decision question

Ask: "What's the consumer doing with this message?"

• Acting on a single message and acking it → Service Bus.
• Reacting to a state change, then forgetting → Event Grid.
• Aggregating, replaying, or stream-processing → Event Hubs.

The wrong-tool tells

You picked the wrong tool if:

• You're rebuilding ordering on top of Event Hubs (→ should've been Service Bus sessions).
• You're polling Service Bus from 50 subscribers (→ should've been Event Grid).
• You're doing 10k msg/sec through a Service Bus queue (→ should've been Event Hubs).