ASB has been around for a while and is a familiar tool for inter service eventing using publish subscribe. This document outlines
- Where ASB is good at.
- What are the primary constraints it introduces.
- How EH addresses this by design and how to address the trade-offs with EH.
And draws the conclusion to what scenarios are best suited to EH vs ASB.
- Single‑message commit – one message, one outcome—simple and fast.
- Ephemeral delivery – messages vanish once acknowledged, perfect for transient notifications.
- Massive fan‑out – four nodes × eight cores = 64 parallel consumers.
| ASB pain point | EH cure |
|---|---|
| Replay gap – no native “send it again.” | Offset rewind – redeploy the fix, reset the offset, self‑heal. |
| Slow‑consumer risk – one laggard drags others down. | Isolated lag – each consumer owns its position. |
| No selective start – can’t backfill “from last Monday.” | Time‑travel starts – pick an offset (“‑2 h”, “midnight UTC”). |
With EH your throughput is capped by your number of partitions. For uses cases that don't require sequential processing, and work at per message transactions, increasing throughput by throwing more compute and per message retries/DLQ is quite useful.
Need both replay semantics and per‑message commit speed? Put an ASB queue in front of the consuming logic:
Producer → Event Hub (immutable stream) → ASB queue → Consumer
The stream remains your source of truth; the queue fans work out across as many workers as you like for the given Consumer.
- Cross‑service events ➜ EventHub streams.
- Inside‑service tasks ➜ ServiceBus queues.
- Need both? Stream it from producers, queue it behind consumers.
Pick the transport that fits the burden—and layer when required.