Messaging & events
Service Bus, Event Grid & Event Hubs
The messaging backbone of Azure Integration Services. Rule of thumb: Service Bus for messages (commands, transactions, ordering), Event Grid for discrete events (reactive pub/sub), Event Hubs for event streams (telemetry firehose).
Which one when?
| Service Bus | Event Grid | Event Hubs | |
|---|---|---|---|
| Payload semantics | Message = intent/command ("process this order") | Event = fact ("blob was created") | Stream of events (millions/sec telemetry) |
| Consumer model | Competing consumers, pull, peek-lock | Push to subscribers (webhooks, Functions, queues) + pull; MQTT | Partitioned consumer groups, offset replay |
| Key features | Queues, topics/subscriptions, sessions (FIFO), transactions, dead-letter, scheduling, dedup, large messages (Premium) | Filtering/routing, CloudEvents schema, retry with dead-letter, system events from 30+ Azure services, MQTT broker for IoT | Kafka-compatible endpoint, capture to storage, retention/replay, Schema Registry |
| Typical consumers | Functions, Logic Apps, Container Apps workers | Functions, Logic Apps, webhooks, Service Bus | Stream Analytics, Fabric/Databricks, Functions |
Service Bus in depth
flowchart LR
P[Producers] -->|send| T[Topic: orders]
T --> S1["Subscription: billing
filter: amount > 0"]
T --> S2["Subscription: shipping
filter: physical = true"]
T --> S3[Subscription: audit
no filter]
S1 --> C1[Billing worker
peek-lock · complete/abandon]
S2 --> C2[Shipping worker]
S3 --> C3[Audit store]
C1 -.max deliveries exceeded.-> DLQ[(Dead-letter queue)]
- Sessions = FIFO ordering + state per session key (per-order, per-device).
- Scheduled delivery & deferral for time-based flows; duplicate detection for idempotency.
- Premium: dedicated capacity, VNet/private endpoints, 100 MB messages, geo-DR — the enterprise default.
- Consumers should be idempotent and handle
abandon/retry storms gracefully.
Event Grid in depth
flowchart LR
subgraph Sources
SRC1[Azure services
Blob · ACR · Key Vault · APIM]
SRC2[Custom apps
CloudEvents]
SRC3[MQTT devices
IoT fleet]
end
EG[Event Grid
topics · namespaces · filters]
subgraph Handlers
H1[Functions]
H2[Logic Apps]
H3[Service Bus queue]
H4[Webhooks / partner]
end
SRC1 --> EG
SRC2 --> EG
SRC3 --> EG
EG -->|subject/type filters| H1
EG --> H2
EG --> H3
EG --> H4
Event Hubs in depth
- Partitioned log: producers write to partitions; consumer groups read independently with offsets — replay is a feature, not a hack.
- Kafka protocol support: point existing Kafka apps at Event Hubs without code changes.
- Capture: automatic archival to Blob/ADLS for batch analytics and RAG ingestion.
- Feeds real-time paths: Stream Analytics, Fabric eventstreams, Functions with checkpointing.
Detailed use cases
Order processing backbone
API accepts order → Service Bus topic → billing/shipping/audit subscriptions process independently. Sessions keep per-order FIFO; DLQ isolates poison messages.
Load leveling
Spiky front-end traffic lands in a queue; fixed-size workers drain at sustainable rate — the database never melts.
Reactive automation
Blob created → Event Grid → Function generates thumbnail; Key Vault secret near expiry → Event Grid → Logic App rotates and notifies.
IoT command & telemetry
MQTT devices publish to Event Grid namespaces; routing sends alerts to Service Bus for guaranteed handling and streams bulk telemetry to Event Hubs.
Clickstream analytics
Web/app events → Event Hubs → Stream Analytics for real-time dashboards + Capture to data lake for ML training sets.
Cross-service saga
Services exchange events via topics; compensating handlers undo committed steps when a downstream step fails — no distributed transactions needed.
Patterns cheat sheet
- Competing consumers — N workers on one queue for elastic throughput.
- Publish/subscribe — topics decouple producers from unknown future consumers.
- Claim check — store big payloads in Blob, send the reference through the bus.
- Queue-based load leveling — buffer bursts, protect downstream systems.
- Outbox / transactional messaging — commit DB write + message send atomically to avoid ghost events.
- Dead-letter operations — monitor, inspect, resubmit; a DLQ nobody reads is a data-loss bug.