Service Bus or Event Hubs?

On almost every Azure project the same question comes up in a workshop: "Service Bus or Event Hubs?". Both carry messages. They do not answer the same need.

The question to ask

Is a message a command to process once, or a fact to keep and read again?

• A command ("invoice this customer", "send this email") must be processed once, by one consumer, and must not be lost when processing fails. That is Service Bus.
• A fact ("the sensor measured 21.4 °C", "the user opened the page") arrives in volume, is read by several independent readers, and can be replayed from a given point. That is Event Hubs.

What Service Bus brings

• Queues and topics with subscriptions filtered by rules.
• A lock on a message while it is processed, a dead-letter queue for what fails, scheduled messages and sessions to keep order per customer.
• Transactions: receive one message and send another atomically.

It is the tool for business processes: orders, payments, orchestration between services.

What Event Hubs brings

• Partitions that absorb millions of events per second.
• Retention: you replay history by moving your offset.
• Consumer groups: monitoring, analytics and archiving read the same stream without getting in each other's way.

It is the tool for telemetry, activity logs and ingestion into a data platform.

The traps I see most often

1. Event Hubs for commands: no dead-letter, no lock; you end up rewriting both by hand so a failure is not lost.
2. Service Bus for telemetry: cost and throughput quickly become the main topic.
3. One queue for everything: one slow consumer blocks the others. One topic per family of business events, one subscription per consumer.

In one sentence

If you need to know a message was processed, choose Service Bus. If you need to replay it, choose Event Hubs. Nothing stops you from having both: facts in Event Hubs, the decisions they trigger in Service Bus.