In AZ-204, messaging services are the core of distributed system integration. This covers how to implement reliable asynchronous communication between systems.
Why Do We Need Messaging Services?
Imagine an online store where, after an order is placed, you need to simultaneously handle payment, reduce inventory, schedule shipping, and send a confirmation email. If all these tasks are directly connected, one slow step blocks the entire pipeline.
A message queue solves this problem like a mailbox. The order system drops an "order complete" message into the queue and immediately moves on to the next task. The payment, inventory, and shipping systems each pull messages from the queue and process them independently, each at their own pace.
Azure Service Bus
Service Bus is like a large company's internal mail system. It goes far beyond simply delivering letters — it is an enterprise-grade message broker that includes delivery confirmation, priority handling, sorted delivery, and retry on failure.
Queue — 1:1 Messaging
One sender sends a message to one receiver. Messages are processed in FIFO (first-in, first-out) order.
| Property | Details | |----------|---------| | Message size | Up to 256 KB (Standard tier) to 100 MB (Premium tier) | | Duplicate detection | If the same message is sent twice, it is automatically processed only once | | TTL (Time-To-Live) | Configurable message expiration time | | Lock-based processing | A message being processed by one receiver cannot be picked up by another |
Topics and Subscriptions — 1:N Messaging
One sender sends a message to multiple receivers. Subscription filters let each receiver get only the messages that match their criteria.
SQL Filter: Filter using SQL-style conditions like Correlation Filter: Filter by a specific property value (better performance than SQL filter)
For example, if an order event topic has three subscriptions: Subscription A (Payment team): Receives all orders Subscription B (VIP team): Receives only orders where Subscription C (Large orders team): Receives only orders where
Advanced Features
| Feature | Description | When to Use | |---------|-------------|------------| | Dead-Letter Queue (DLQ) | A separate queue where failed messages accumulate | Analyzing and reprocessing failed messages | | Message Session | Processes messages with the same session ID in order | When order matters, like processing steps of a single order | | Scheduled Messages | Schedules a message to be processed at a specific time | Scheduled delivery, deferred processing | | Auto-forward | Automatically forwards from one queue/subscription to another | Message routing | | Transaction | Processes multiple message operations atomically | Send and receive as a single unit |
Using the Service Bus SDK
PeekLock vs ReceiveAndDelete
| Mode | Behavior | When to Use | |------|----------|------------| | PeekLock (default) | Retrieves the message in a locked state; must explicitly complete after processing | When message loss is not acceptable (safe, recommended) | | ReceiveAndDelete | Deletes from the queue immediately upon retrieval | When occasional loss during processing is acceptable (faster but risky) |
Azure Queue Storage
Queue Storage is like a neighborhood mailbox. It provides only the basic function of holding letters — no extra services — but it is inexpensive and easy for anyone to use.
| Property | Details | |----------|---------| | Message size | Up to 64 KB | | Number of messages | Unlimited (up to storage account capacity) | | Visibility timeout | The time a message is hidden from other receivers while one receiver is processing it | | Retention | Up to 7 days | | Access method | HTTP/HTTPS REST API |
Queue Storage is part of an Azure Storage account, so you can use it in the same account as Blob Storage.
Service Bus vs Queue Storage Comparison
| Aspect | Service Bus | Queue Storage | |--------|------------|--------------| | Message size | Up to 100 MB (Premium) | Up to 64 KB | | Message ordering | FIFO sessions supported | Not guaranteed | | Duplicate detection | Supported | Not supported | | Topics/Subscriptions (1:N) | Supported | Not supported | | Dead-letter queue | Supported | Not supported | | Transactions | Supported | Not supported | | Cost | Relatively higher | Inexpensive | | Best for | Enterprise, complex workflows | Simple queuing, high volume, low cost |
!Service Bus versus Queue Storage
Exam Key Points
"Enterprise-grade reliable messaging, complex workflows" -- Azure Service Bus
"1:1 message delivery, FIFO" -- Service Bus Queue
"1:N message delivery, per-subscription filters" -- Service Bus Topic + Subscription
"Filter messages using SQL-style conditions" -- SQL Filter
"Filter by property value, better performance than SQL filter" -- Correlation Filter
"Where failed messages are stored for analysis" -- Dead-Letter Queue (DLQ)
"Process messages with the same session ID in order" -- Message Session
"Hold a lock until processing is confirmed (safe)" -- PeekLock
"Delete immediately upon receipt (fast but risks loss)" -- ReceiveAndDelete
"Simple queuing, low cost, messages under 64 KB" -- Azure Queue Storage
"Visibility timeout: hides a message while it is being processed so other receivers cannot grab it" -- Queue Storage visibility timeout