5.1.4. Design Messaging and Event-Driven Architectures
💡 First Principle: The question that picks a messaging service is not "which one is fastest" but "what does the sender expect to happen next?" A message carries a contract — someone must process this order — so the broker has to hold it, lock it, retry it and park it somewhere when it keeps failing. An event is a notification that something already happened; the publisher does not care who reacts, so the service only has to fan it out reliably. A stream is a time-ordered series of events that is valuable in aggregate, so it is read, re-read and analyzed rather than consumed and deleted. Name which of the three you are moving and most of the service choice makes itself.
Scenario: A retailer is redesigning its order platform. Payment commands must be processed in order for each customer, and a resent command must not be charged twice; the warehouse must react whenever a partner uploads a shipping manifest to Blob Storage; and the web tier emits 200,000 clickstream events per second that the analytics team wants to replay for up to a month.
That scenario needs three different services, and the exam rewards recognising each shape rather than picking one broker for everything. Microsoft's own comparison frames it the same way: Event Grid for reactive event routing, Event Hubs for big-data streaming and ingestion, Service Bus for enterprise transactional messaging (Compare messaging services).
The decision table:
| Criterion | Storage queues | Service Bus | Event Grid | Event Hubs |
|---|---|---|---|---|
| Carries | Simple work items | High-value messages with a contract | Discrete events (state changes) | Event streams (time-ordered series) |
| Ordering | Not guaranteed | FIFO with sessions | No guarantee | Per partition |
| Duplicate detection | No | Yes | No | No |
| Dead-lettering | No automatic dead-letter (app checks DequeueCount) | Automatic | Yes, to a blob container — off by default | No |
| Replay | No | No — settled messages are gone | No | Yes, within the retention period; Capture to storage |
| Delivery model | Consumer polls | Consumer receives (long polling, push-style SDKs) | Push to handlers, or pull on namespace topics | Consumer reads from an offset per consumer group |
| Pick it when | A cheap backlog, a queue larger than 80 GB, or server-side transaction logs | Orders, payments, workflows, pub/sub with filters | React to Azure resource or app events without polling | Telemetry, clickstream, log ingestion at millions of events per second |
Storage queues vs Service Bus queues. Both are queues; the difference is how much the broker does for you (Storage queues and Service Bus queues compared):
| Requirement | Points to |
|---|---|
| Guaranteed FIFO, duplicate detection, transactions across several messages, automatic dead-lettering | Service Bus |
| Messages larger than 64 KB (Service Bus: 256 KB Standard, up to 100 MB Premium over AMQP) | Service Bus |
| A queue that must grow past 80 GB (Service Bus queues are sized 1 GB to 80 GB) | Storage queues |
| A server-side log of every transaction against the queue | Storage queues |
| An unlimited number of queues (Service Bus Standard allows 10,000 per namespace) | Storage queues |
Service Bus tiers are a feature decision, not only a capacity one (Premium messaging):
| Tier | What it adds |
|---|---|
| Basic | Queues only |
| Standard | Topics and subscriptions, sessions, transactions, duplicate detection — shared capacity, billed per operation |
| Premium | Dedicated messaging units, messages up to 100 MB, virtual network integration and private endpoints, geo-replication, JMS 2.0 |
Topics fan a message out; filters decide who gets it. Every subscription starts with a true filter that selects everything. SQL filters evaluate a SQL-like expression; correlation filters match properties by equality and are much cheaper to evaluate, so prefer them when equality is enough. Neither can read the message body — route on properties the publisher sets (Topic filters).
Event Grid delivery is at-least-once with retries, not guaranteed delivery. Push delivery retries on an exponential schedule for up to 24 hours (defaults: 30 attempts, 1,440-minute event time-to-live), but a 400 or 413 from the handler is never retried. Dead-lettering to a blob container is off by default; without it, those events are simply dropped (Delivery and retry). Choose pull delivery on a namespace topic when the consumer cannot expose an endpoint or must receive events over a private link — private links are possible only with pull delivery (Event Grid overview). An event subscription filters before delivery — by event type (such as BlobCreated) and by subject prefix or suffix, and a Blob Storage event's subject ends with the blob name, so one file type can be selected without the handler ever seeing the rest (Event filtering).
Event Hubs tier sets how far back you can replay (Event Hubs quotas): Basic retains events for 1 day with one consumer group, Standard for up to 7 days, Premium and Dedicated for up to 90 days. Each downstream reader gets its own consumer group so it keeps its own position in the stream.
Payload too big for the broker? Send a claim check. The Claim-Check pattern stores the payload in Blob Storage and sends only a reference through the messaging system, so the broker never carries the bulk. If the payload fits a tier you can choose — Service Bus Premium takes AMQP messages up to 100 MB — inline delivery is simpler (Claim-Check pattern).
⚠️ Exam Trap: "Event Hubs keeps order, so use it for payment commands." Event Hubs orders within a partition, but it has no duplicate detection, no dead-lettering and no per-message settlement. Ordered, deduplicated, retry-until-settled work is Service Bus with sessions and duplicate detection.
⚠️ Common Pitfall: Treating a Storage queue as FIFO. Messages are usually first-in-first-out, but a message whose visibility timeout expires reappears behind newer ones. If ordering is a requirement, the answer is Service Bus sessions.
Key Trade-Offs:
- Broker features vs cost and scale: Service Bus does the hard work (ordering, dedup, transactions) at a higher per-message cost and an 80 GB queue ceiling. Storage queues are cheaper and larger, and push every one of those guarantees back into your code.
- Push vs pull for events: push delivery removes polling but requires a reachable endpoint; pull delivery lets the consumer control its pace and stay private, at the cost of running a reader.
Reflection Question: For each flow in the retailer scenario — payment commands, manifest uploads and clickstream — which property of the data (contract, notification or stream) decides the service, and what would break first if you forced all three through the same broker?
