The one-line distinction
- Service Bus — a message broker. Something must be done. Reliability and ordering matter more than throughput.
- Event Grid — an event router. Something has happened. Multiple independent subscribers may want to know.
- Event Hubs — a streaming ingestion pipeline. A great deal is happening continuously and needs to be captured for downstream processing.
An informal analogy: Service Bus is a registered letter, Event Grid is a push notification, and Event Hubs is a firehose with a recording buffer.
Full comparison
| Attribute | Service Bus | Event Grid | Event Hubs |
|---|---|---|---|
| Primary purpose | Enterprise messaging | Reactive event routing | Telemetry streaming |
| Model | Pull (and push via handler) | Push | Pull from partitioned log |
| Delivery | At-least-once; exactly-once via sessions and transactions | At-least-once | At-least-once |
| Ordering | FIFO per session | Not guaranteed | Guaranteed within a partition |
| Throughput | Thousands per second | Millions per second | Millions per second |
| Max payload | 256 KB Standard / 100 MB Premium | 1 MB | 1 MB Standard / 20 MB Premium |
| Retention | Until consumed or TTL expires | 24 hours retry window | 1–7 days Standard, up to 90 Dedicated |
| Replay | No | No | Yes, by offset or timestamp |
| Dead-letter | Yes, built in | Yes, to Storage | No |
| Filtering | SQL and correlation filters on subscriptions | Subject prefix/suffix and advanced filters | None; consumers filter themselves |
| Transactions | Yes | No | No |
| Typical cost driver | Operations and namespace tier | Operations | Throughput units |
Service Bus — the exam-critical details
PeekLock versus ReceiveAndDelete
PeekLock is the safe default and the expected answer in almost every scenario. The message is locked but not deleted; the consumer completes it explicitly after successful processing. If the consumer crashes, the lock expires and the message becomes available again.
ReceiveAndDelete removes the message the moment it is delivered. If the consumer fails mid-processing the message is lost. It is only correct when the scenario explicitly states that occasional loss is acceptable in exchange for lower latency.
Dead-letter queue causes
A message moves to the dead-letter queue when it exceeds MaxDeliveryCount, when its TTL expires, when it fails a subscription filter evaluation, or when the application explicitly dead-letters it. Every one of these has appeared as an exam distractor.
Sessions
Sessions provide FIFO ordering for all messages sharing a SessionId. If a scenario says "messages for the same customer must be processed in order", the answer is a session-enabled queue with SessionId set to the customer identifier.
Topics and subscriptions
A topic is a queue with multiple independent subscriptions. Each subscription receives its own copy and can apply a filter. This is how you achieve publish-subscribe within Service Bus while retaining dead-lettering and ordering.
A scenario describing fan-out to multiple subscribers does not automatically mean Event Grid. If the scenario also requires dead-lettering, ordering, or transactions, the answer is a Service Bus topic with multiple subscriptions.
Event Grid — the exam-critical details
Retry policy
Event Grid retries with exponential backoff for up to 24 hours by default, or until the configured maximum delivery attempts are exhausted. Undeliverable events can be routed to a dead-letter Storage account, which must be configured explicitly — it is not on by default.
Idempotency is mandatory
Because delivery is at-least-once, a handler can receive the same event more than once. Any scenario mentioning duplicate processing with Event Grid is testing whether you know the handler must be idempotent.
Filtering
Subscriptions filter on event type, subject prefix and suffix, and advanced filters over event data fields. Filtering at the subscription reduces cost and load compared with filtering in the handler.
System versus custom topics
System topics are emitted by Azure services themselves — a blob created, a resource group deleted, a Cosmos DB throughput change. Custom topics carry your own application events. Domain topics group many custom topics under one endpoint.
Event Hubs — the exam-critical details
Partitions
A partition is an ordered, append-only log. Ordering is guaranteed within a partition only. Events with the same partition key always land on the same partition. Partition count is fixed at creation on Standard tier and cannot be changed afterwards — a frequent exam point.
Consumer groups
A consumer group is an independent view over the whole event stream with its own offset. Multiple downstream applications each get their own consumer group so they can read at their own pace without interfering. The default consumer group is named $Default.
Capture
Event Hubs Capture automatically writes batches to Blob Storage or Data Lake in Avro format on a size or time trigger. If the scenario mentions archiving raw telemetry for later batch analysis with no code, Capture is the answer.
Checkpointing
Consumers persist their offset to a checkpoint store, typically Blob Storage. On restart the consumer resumes from the last checkpoint. Infrequent checkpointing means more reprocessing after a failure; frequent checkpointing costs more storage operations.
Scenario phrase to answer mapping
| Phrase in the scenario | Expected answer |
|---|---|
| "must not be lost" / "guaranteed processing" | Service Bus with PeekLock |
| "in order per customer / per tenant" | Service Bus with sessions |
| "retry failed messages then quarantine" | Service Bus dead-letter queue |
| "atomic across two operations" | Service Bus transactions |
| "react when a blob is uploaded" | Event Grid system topic |
| "notify several independent subscribers" | Event Grid custom topic |
| "filter by subject prefix" | Event Grid subscription filter |
| "millions of telemetry events per second" | Event Hubs |
| "replay the last two days of events" | Event Hubs with offset or timestamp |
| "archive raw stream to storage without code" | Event Hubs Capture |
| "two teams consume the same stream independently" | Event Hubs consumer groups |
| "scale a consumer to zero when the queue is empty" | Container Apps with the KEDA Service Bus scaler |
Combining the three
Production architectures frequently use all three, and the exam sometimes presents this as a case study. A representative pipeline for an AI application:
- Event Hubs ingests raw interaction telemetry from the client at high volume.
- Event Grid fires when a new document lands in Blob Storage, triggering an Azure Function to generate embeddings.
- Service Bus carries the resulting indexing commands to a worker that writes to Cosmos DB, with dead-lettering for poison messages.
Each service is doing what it is designed for: streaming, reacting, and reliably commanding.
Summary
Read the scenario for the constraint rather than the surface description. Reliability, ordering, and transactions point to Service Bus. Reactive notification with fan-out points to Event Grid. High-volume ingestion with replay points to Event Hubs. Practise this mapping on the free question set, and review the full decision matrix before your exam.