11.1 Messaging Architecture Design (Service Bus, Queue Storage)

Why Messaging Architecture Design Matters on AZ-305

Messaging design sits inside Design infrastructure solutions, the highest-weighted AZ-305 domain at 30-35%, under the "Design an application architecture" functional subgroup. This is where the exam stops asking what a service does and starts asking which of several plausible services is correct for this exact requirement. The two core Azure messaging services — Azure Service Bus and Azure Storage Queues — both move a message from a producer to a consumer asynchronously, so a candidate who only knows the marketing description of each will miss scenario questions that hinge on a single differentiating requirement: strict ordering, duplicate suppression, pub-sub fanout, transactional batching, or raw message size. Expect at least one AZ-305 item that gives you five or six requirements and asks you to eliminate three services before landing on the right one.

Core Concepts and Terminology

Asynchronous messaging decouples a producer from a consumer: the producer writes a message and moves on; the consumer reads and processes it whenever it is ready. This buys resilience (a consumer outage does not lose work) and independent scaling, but requires the consumer to handle at-least-once delivery — the same message can arrive more than once, so consumer logic must be idempotent (processing the same message twice produces the same result as processing it once).

Azure Service Bus

Service Bus is Microsoft's enterprise message broker, built for reliable, ordered, and sometimes transactional business messaging.

• Queues — point-to-point; each message is processed by exactly one competing consumer.
• Topics and Subscriptions — publish-subscribe; one published message can be delivered to many independent subscriptions, each with its own SQL-like or correlation filter rule, so different downstream systems can each receive only the messages they care about from the same feed.
• Sessions — group related messages by a session key so a single consumer processes them strictly in order (first-in, first-out, or FIFO) and can maintain state across the sequence. Without sessions, Service Bus delivery order is not guaranteed once more than one consumer is competing.
• Dead-letter queue (DLQ) — an automatic sub-queue that quarantines a message once MaxDeliveryCount is exceeded (default 10 delivery attempts) or its time-to-live (TTL) expires, so poison messages do not block the main queue forever.
• Duplicate detection — an optional history window (default 10 minutes, configurable up to 7 days) that uses each message's MessageId to silently drop resends from a retrying client.
• Transactions — batch multiple send/complete operations into one atomic unit within a single entity (and across entities in Premium), useful when a message must be completed and a new one sent together or not at all.
• Auto-forwarding — chains a queue or topic subscription to another queue/topic (up to four hops) for simple two-stage routing without custom relay code.

Tiers: Basic and Standard are shared multi-tenant infrastructure billed per operation, capped at 256 KB per message. Premium is dedicated capacity billed in Messaging Units (1, 2, 4, 8, or 16), giving predictable low-latency performance, virtual network (VNet) service endpoints and private endpoints, availability-zone support, and messages up to 100 MB — but only over the Advanced Message Queuing Protocol (AMQP); the older SBMP and HTTP protocols stay capped at 1 MB even on Premium. Premium also adds geo-disaster recovery through a paired namespace with manual failover for regional outages.

Azure Storage Queues

A queue that lives inside a Storage Account, aimed at simplicity and cost rather than enterprise features.

• Message size capped at 64 KB; total queue capacity is limited only by the storage account (up to 500 TB).
• At-least-once delivery, no guaranteed ordering, and no pub-sub — a message goes to whichever single consumer dequeues it first.
• Per-message TTL is configurable (default 7 days; can be set to -1 for messages that never expire).
• A visibility timeout hides a dequeued message from other consumers while it is being processed; if the consumer crashes before deleting it, the message reappears for another consumer to retry.
• Far cheaper per operation than Service Bus — the right default when an application just needs a durable backlog of work items and none of Service Bus's enterprise guarantees.

Decision Framework

• Need to fan one event out to several independent downstream systems → Service Bus Topics.
• Need strict per-key ordering plus duplicate suppression plus transactional completion → Service Bus with Sessions and a duplicate-detection window sized to your client's retry interval.
• Need a cheap, simple, very high-volume backlog with no ordering requirement → Storage Queue.
• Message is larger than the queue's limit (for example, a multi-megabyte document) → use the claim-check pattern: store the payload in Blob Storage and enqueue only a reference, regardless of which queue technology you pick, or move to Service Bus Premium if the whole message truly must travel through the broker.
• Need predictable low latency, VNet isolation, and geo-disaster recovery for a regulated workload → Service Bus Premium.

Exam Scenario

An order-management platform must publish each new order so that inventory, shipping, and invoicing systems each receive and process it independently. Orders from the same customer must be processed strictly in the order placed, and a flaky mobile client sometimes submits the same order twice within a few seconds. The correct design is a Service Bus Topic with three subscriptions (one per downstream system), Sessions enabled and keyed on customer ID to preserve per-customer ordering, and a duplicate-detection window covering the client's retry interval. A Storage Queue is wrong because it cannot fan out to three independent subscribers or guarantee ordering; Event Grid (covered next) is wrong because it is built for lightweight, fire-and-forget notifications, not ordered, deduplicated, guaranteed-delivery business transactions.