Recommend a Messaging Architecture — Lesson

An e-commerce platform processes orders with a chain of services: order capture, inventory, fulfilment, billing, notification. The architect's first design uses HTTP calls between services — synchronous, "simple", and beautiful in the architecture diagram. The first Black Friday it falls over: the billing service slows down for an unrelated reason, every upstream service backs up, and within ten minutes nothing accepts new orders. The fix is one architectural change: replace the HTTP chain with an async messaging path through Service Bus. Order capture writes one message to a queue and returns to the user instantly; downstream services consume at their own pace; a slow billing service no longer takes down the front end. The next Black Friday is silent. This lesson is about choosing the right messaging architecture from Azure's four canonical options — Queue Storage, Service Bus, Event Hub, Event Grid — so the next Black Friday is silent for your customers too.

We will work through Azure's messaging story the way the AZ-305 exam expects you to: distinguishing brokered messaging (Queue Storage, Service Bus) from event streaming (Event Hubs) from event distribution (Event Grid), and configuring each correctly. Reference: the AZ-305 exam study guide, particularly Chapter 4 Skill 4.2 on messaging and Azure documentation on Service Bus, Event Hubs, and Event Grid.

Why This Matters

Messaging is the load-bearing infrastructure of every modern distributed system. Pick the wrong messaging service and a workload either fails under load, loses data, or runs at $10{\times}$ the necessary cost. The AZ-305 exam tests this LO heavily because Azure offers four genuinely different messaging services and architects routinely confuse them. The most common mistake is treating Event Hubs and Service Bus as interchangeable — they are not. Event Hubs is event streaming (high throughput, ordered, replayable); Service Bus is brokered messaging (low-volume, transactional, FIFO with sessions, dead-lettering). Building a "messaging service" by picking the wrong one leads to weeks of remediation.

The career payoff is concrete: every "we need an async pattern here" workshop, every "the front end shouldn't wait for the back end" review, and every event-sourcing or CQRS design touches this LO. If you can match a workload — order pipeline, telemetry stream, partner integration, transactional CQRS, fan-out notification — to the right messaging service and configure it correctly (sessions, dead-letter queues, partitions, consumer groups, schemas), you will pass this slice of the exam and design messaging like a senior architect.

Prerequisites

Before working through this lesson, make sure you can answer each prompt below in one or two sentences.

• Synchronous vs asynchronous communication. Can you describe the difference and give one advantage of each? — Self-check: which model couples sender and receiver lifecycle?
• Queue vs pub/sub patterns. Are you fluent with point-to-point queues vs publish/subscribe topics? — Self-check: which one has one consumer per message?
• Idempotency. Do you know why messaging clients should be idempotent? — Self-check: name a scenario where a message could be delivered twice.
• Pull vs push delivery. Can you contrast a pull (consumer fetches) vs push (broker delivers) model? — Self-check: which one is Event Grid?
• Throughput basics. Are you familiar with the difference between 10 msg/sec, $1{,}000$ msg/sec, and $1{,}000{,}000$ msg/sec workloads? — Self-check: which Azure service is designed for the highest end?

If any of these feels shaky, pause and review the messaging intro modules in Unit 4 of the AZ-305 guide before continuing.

Learning Objectives

By the end of this lesson, you will be able to:

1. Analyse a workload's messaging requirements (throughput, ordering, durability, FIFO needs, fan-out, schema enforcement) and translate them into a messaging service.
2. Evaluate trade-offs between Azure Queue Storage, Service Bus (Standard / Premium / queues / topics), Event Hubs, and Event Grid.
3. Design a Service Bus topology using sessions, dead-letter queues, scheduled messages, and Premium namespace features for a workload with transactional semantics.
4. Configure Event Hubs partitioning, consumer groups, and checkpointing for a high-throughput telemetry pipeline.
5. Recognise common anti-patterns — using Event Hubs for transactional workflows, Service Bus for telemetry streams, Storage Queue for $> 1{,}000$ msg/sec — and rewrite them.
6. Decide between push (Event Grid, webhook) and pull (Service Bus, Event Hubs, Queue Storage) delivery for a given integration.

Building Blocks

Read this section as a glossary. Each term follows the same shape: an everyday analogy, a formal definition, then the reason it matters for the exam.

Brokered messaging — A pattern where a broker stores messages until consumers pick them up. Like a mailroom: senders drop letters in, recipients collect at their own pace. Formally, message-oriented middleware that decouples sender and receiver via durable storage. It matters because brokered messaging is the right pattern for transactional workflows and async work where reliability is paramount.

Event streaming — A pattern where events are written to an append-only log and many consumers can replay them. Like a stenographer's transcript: the record is read-only, ordered, and replayable. Formally, a log-based system where partitions retain events for a configurable time and consumers track their own position. It matters because event streaming is the right pattern for telemetry, IoT, real-time analytics — high-throughput workloads that need replayability.

Event distribution — A pattern where the broker pushes events to subscribed handlers. Like a doorbell with multiple chimes: a single press triggers everyone wired up. Formally, a serverless push-based event system where producers emit events and the broker delivers them to webhooks, Functions, or other endpoints. It matters because event distribution is the right pattern for "X happened — go do something" use cases, especially reactive automation.

Azure Queue Storage — A basic queueing service that lives inside a storage account. Like a notepad with a wait-list. Formally, a queue stored as part of Microsoft.Storage/storageAccounts, supporting messages up to 64 KB, with at-least-once delivery and visibility-timeout semantics. It matters as the cheapest queue option for low-volume, low-feature-need workloads — but it lacks FIFO, sessions, and most enterprise messaging features.

Azure Service Bus — Azure's enterprise messaging broker. Formally, Microsoft.ServiceBus/namespaces resource with queues and topics (pub/sub) child resources. Standard or Premium tier. Supports sessions (FIFO group), dead-letter queues, transactions, scheduled messages, duplicate detection, 100 KB to 100 MB messages depending on tier. It matters because Service Bus is the right answer for transactional / business workflows — order pipelines, billing flows, partner integration.

Azure Event Hubs — Azure's event streaming platform. Formally, Microsoft.EventHub/namespaces resource with eventhubs (a.k.a. "event hub" entities) and consumerGroups children. Standard / Premium / Dedicated tiers. Partition-based; consumers track their own offset. It matters because Event Hubs is the right answer for telemetry / IoT / clickstream / log streaming — millions of events per second.

Azure Event Grid — Azure's serverless event distribution service. Formally, Microsoft.EventGrid/topics (custom), systemTopics (Azure resource events), and eventSubscriptions (handlers). Push delivery with retry, dead-lettering, and CloudEvents v$1.0 schema. It matters because Event Grid is the right answer for "fire-and-forget" event distribution — reacting to Azure resource events, custom domain events, partner webhooks.

Consumer group — A logical view of an Event Hub for one consumer. Like a Netflix profile: each profile (consumer group) tracks its own watch position. Formally, a named position pointer that lets multiple independent consumers process the same stream. It matters because consumer groups enable multi-tenant or multi-purpose consumption of the same event stream without interfering with each other.

Dead-letter queue (DLQ) — A sub-queue where messages that cannot be processed land. Like a problem-mail folder. Formally, Service Bus queues and topic subscriptions have a built-in DLQ accessed via <queue>/$DeadLetterQueue; Event Grid has dead-letter destinations. It matters because DLQ is what stops a poison message from blocking the queue forever.

Session (Service Bus) — A FIFO grouping of messages by SessionId. Like an airport queue at one specific check-in counter — order is preserved within the counter. Formally, messages sharing a SessionId are locked to a single consumer and delivered in FIFO order. It matters because it is the only way to get FIFO from Service Bus — a session-less queue delivers in arrival order but allows concurrent consumers to interleave.

Deep Dive

1. The four messaging services — pick by pattern, not by familiarity

The first cut is conceptual: brokered messaging, event streaming, or event distribution?

[!TIP] A test that separates messaging from streaming: does each message represent a single instruction to one consumer (use brokered), or a fact in a stream that many independent consumers might replay (use streaming)? Order events are usually streaming if they feed analytics; messaging if they feed a fulfilment pipeline.

2. Service Bus deep dive — sessions, DLQ, scheduled, transactions

Service Bus is the workhorse of business workflows. Five features matter for the exam.

Sessions group related messages by SessionId. Within a session, messages are delivered in FIFO order to a single consumer. Without sessions, multiple consumers can pull from the queue concurrently (no FIFO).

Dead-letter queue (DLQ) is a sub-queue accessed via <queue>/$DeadLetterQueue. Messages land here automatically after exceeding maxDeliveryCount, on TTL expiry, or via explicit deadLetter() call. Always have an operational process to drain and investigate the DLQ.

Scheduled messages let producers enqueue a message with a future delivery time. Useful for retry-after-delay, scheduled reminders, batch-up windows.

Transactions let producers send / receive / settle multiple messages atomically. Premium tier only for cross-entity transactions.

Premium tier offers dedicated capacity (no noisy-neighbour), geo-disaster recovery, partitioning, AMQP-over-WebSockets for client compatibility, and up to 100 MB message size.

[!IMPORTANT] requiresSession: true cannot be changed after queue creation. If you discover halfway through a project that FIFO is required, you cannot enable sessions on an existing queue — you have to create a new one and migrate.

[!WARNING] requiresDuplicateDetection window defaults to 10 minutes and the max is 7 days. If a producer can re-send the same message $> 7$ days later (e.g., a retry queue with long backoff), duplicate detection will not catch it — design the producer to be idempotent at the application level.

3. Event Hubs deep dive — partitions, consumer groups, checkpointing

Event Hubs is the event streaming service. The exam frequently tests partition-related concepts.

[!TIP] Event Hubs is partition-bound — set the partition count high enough at creation time to absorb future scale. Standard tier partitions cannot be increased without re-creating the entity.

[!NOTE] Event Hubs Capture automatically archives events to Blob / Data Lake in Avro format — useful for retroactive batch analytics without writing custom consumers. Premium tier required for many advanced features.

4. Event Grid deep dive — push delivery, filtering, retries

Event Grid is the serverless event distribution backbone. The model is "push to subscribers".

[!TIP] Use CloudEvents schema for new event topics — it is the open standard and supported by handlers across providers. Custom Event Grid topics support both schemas.

5. Choosing between messaging and streaming — the "is it a fact or an instruction?" test

The exam often tests whether to use Service Bus or Event Hubs for the same workload description. Use this test:

6. Observability — tracking messaging health

Production messaging needs metrics and trace IDs end to end.

[!TIP] Alert on DLQ depth $> 0$ for tier-1 queues. A poison message in the DLQ is silent unless someone is watching — production messaging needs a process to drain and investigate the DLQ.

Worked Examples

Easy — pick the messaging service for an order pipeline

Problem. An order service needs to enqueue $\sim 100$ orders/sec for a downstream fulfilment service. The order pipeline must preserve FIFO order per customer. Recommend a messaging service.

Solution. Service Bus queue with sessions, SessionId = customerId. Sessions are the only way to get FIFO from Service Bus. Standard tier supports $\sim 2{,}000$ msg/s, more than enough for 100 orders/sec. Configure DLQ on message expiration and maxDeliveryCount = 10 so poison messages don't block the queue forever.

[!NOTE] If FIFO weren't required, a session-less queue would have allowed multiple concurrent consumers per queue at higher overall throughput.

Medium — telemetry pipeline with multi-consumer analytics

Problem. An IoT platform receives $50{,}000$ device telemetry events/sec from $1{M}$ devices. Two downstream systems consume the stream: a real-time alerting service and a daily analytics ETL. Recommend a messaging service and topology.

Solution. Event Hubs Premium tier with 32 partitions, 2 PUs. Two consumer groups: alerting-realtime and analytics-etl. Each consumer group reads independently with its own checkpointing in Blob. Producers use deviceId as partition key so events from one device land in one partition. Enable Capture to archive to Data Lake for the ETL's reprocessing needs.

Hard — multi-pattern workflow with fan-out

Problem. A retailer publishes "order completed" events. Three downstream systems must react: (a) the warehouse picks/packs (must be transactional), (b) the analytics warehouse appends the event (high throughput), (c) the marketing platform sends an SMS (best-effort). Recommend a messaging architecture.

Solution. Use three different mechanisms in parallel:

The order service publishes the event once to its own pattern (Service Bus topic). A subscription forwards via a Function to Event Hubs for analytics and another subscription emits to Event Grid for marketing. This way each downstream gets the message in the way that fits its needs.

[!IMPORTANT] Resist the urge to pick "one messaging service for everything". Different downstream consumers have different semantics requirements; matching each to the right service is a core architecture skill.

Visual Explanations

Figure 1 — Messaging-service decision flow

Walk the tree. The first cut (throughput) excludes Queue Storage; the second (replay) separates Event Hubs from the brokered options; the third (transactions/sessions) is the Service Bus signal.

Figure 2 — Topic-based pub/sub fan-out

Topic subscriptions are the canonical pub/sub pattern in Service Bus. Each subscription has its own consumer set, filter, DLQ, and TTL — independent semantics per consumer.

Figure 3 — Quick service comparison

Common Mistakes

❌ Myth: "Event Hubs and Service Bus are interchangeable." ✅ Reality: They solve different problems. Event Hubs is event streaming (high throughput, ordered per partition, replayable). Service Bus is brokered messaging (transactional, FIFO with sessions, DLQ). Picking the wrong one means rewriting later. Why it's tricky: Both store messages temporarily; both have consumers. The semantics — replay, ordering, transactions — are the differentiator.

❌ Myth: "Service Bus queues are always FIFO." ✅ Reality: Without sessions, a Service Bus queue delivers messages in arrival order but allows concurrent consumers to interleave. True FIFO requires requiresSession: true and a SessionId on each message. Why it's tricky: "Queue" mentally implies FIFO. Service Bus relaxes that for parallelism unless you opt in to sessions.

❌ Myth: "Queue Storage is fine for production — it's part of Storage." ✅ Reality: Queue Storage lacks FIFO, sessions, transactions, DLQ, scheduled messages, duplicate detection, and most enterprise features. It is acceptable for simple low-feature work distribution; production messaging usually wants Service Bus. Why it's tricky: Queue Storage is cheaper and "always available" with any storage account. Its limitations matter more than its price.

❌ Myth: "Event Grid is just another pub-sub." ✅ Reality: Event Grid is push-based fan-out to handlers. It does not retain events for replay, it does not have consumer groups, and it cannot guarantee ordering. Event Grid for telemetry streaming is the wrong choice. Why it's tricky: "Event" in the name conflates with Event Hubs. The model is push vs pull.

Practice Exercises

🟢 Exercise 1. A workload needs to process $\sim 50$ work items/day. Each item is independent and not order-sensitive. Cost matters. Recommend a service.

▶💡 Hint

Low volume, no advanced features.

▶✅ Solution

Azure Queue Storage. At 50 items/day, Queue Storage's per-operation pricing is essentially free, and the lack of FIFO/sessions/DLQ doesn't matter for this workload. Service Bus would work too but adds namespace cost ($\sim $10$/month even at Standard tier with no traffic).

🟡 Exercise 2. An IoT platform ingests $200{,}000$ events/sec from $5{M}$ devices. Two consumers — alerting and analytics — process the stream independently. Recommend a service and topology.

▶💡 Hint

High throughput, multiple independent consumers, replayable.

▶✅ Solution

Event Hubs Premium tier with 32 partitions and 4 PUs (each PU = $\sim 50{,}000$ events/sec). Two consumer groups: alerting and analytics. Use deviceId as partition key for ordered per-device events. Set retention to 7 days for replay. Consider enabling Capture to archive to Data Lake.

🟡 Exercise 3. A team wants to react to new blobs being created in a storage account by triggering a Function and a Logic App. Recommend a service.

▶💡 Hint

Reactive to Azure resource events.

▶✅ Solution

Event Grid with a system topic for the storage account. Create two event subscriptions: one to a Function (BlobCreated filter), one to a Logic App. Both handlers receive the same event independently. Configure a dead-letter destination Blob container in case a handler is unreachable.

🔴 Exercise 4. A workflow uses a Service Bus queue with maxDeliveryCount: 10. A poison message has been failing for a week. The team finds the DLQ has $50{,}000$ messages. Diagnose and recommend.

▶💡 Hint

DLQ growth signals failure mode.

▶✅ Solution

The DLQ growth indicates one of: (a) a single poison message variant that keeps being produced, (b) a consumer bug failing on all messages of a certain shape, (c) a downstream system permanently unavailable. The fix has two parts: (1) drain and investigate the DLQ — what are the messages? — and either repair / replay them or discard; (2) add an alert on DLQ depth $> 0$ so future poison-message events are noticed within minutes, not weeks.

🔴 Exercise 5. A retail platform sends "order placed" events to a Service Bus topic with 5 subscriptions. One subscription's consumer has been broken for 4 days. The producer is now backed up. Diagnose.

▶💡 Hint

Each subscription has its own queue.

▶✅ Solution

Each subscription has its own message store. The broken subscription's queue grows until it hits the namespace size quota, at which point producers receive QuotaExceededException. The fix: drain or purge the broken subscription's messages (e.g., DLQ them), or set the subscription's defaultMessageTimeToLive to a sane value so old messages expire automatically. Long-term: add an alert on per-subscription message count.

🟢 Exercise 6. True or false: Service Bus Standard tier supports geo-disaster recovery.

▶💡 Hint

Check which tier is required for paired-namespace failover.

▶✅ Solution

False. Geo-disaster recovery (paired-namespace failover) is a Premium-tier feature. Standard tier supports zone redundancy in supported regions but does not have a cross-region failover mechanism. For tier-1 workloads requiring cross-region resilience, use Premium.

🟡 Exercise 7. Design a Bicep snippet for an Event Hub Premium namespace with 1 PU, zone-redundant, and an event hub with 16 partitions, 4-day retention, and Capture to Blob.

▶💡 Hint

Microsoft.EventHub/namespaces + eventhubs with captureDescription.

▶✅ Solution

bicepCopy

resource ns 'Microsoft.EventHub/namespaces@2024-01-01' = { name: 'evhns-clicks' location: location sku: { name: 'Premium', tier: 'Premium', capacity: 1 } properties: { zoneRedundant: true } } resource hub 'Microsoft.EventHub/namespaces/eventhubs@2024-01-01' = { parent: ns name: 'clickstream' properties: { partitionCount: 16 messageRetentionInDays: 4 captureDescription: { enabled: true encoding: 'Avro' intervalInSeconds: 300 sizeLimitInBytes: 314572800 destination: { name: 'EventHubArchive.AzureBlockBlob' properties: { storageAccountResourceId: stId, blobContainer: 'capture', archiveNameFormat: '{Namespace}/{EventHub}/{PartitionId}/{Year}/{Month}/{Day}/{Hour}/{Minute}/{Second}' } } } } }

Summary & Concept Map

The headline takeaways from this lesson:

• Four messaging services, three patterns. Brokered queue/pub-sub (Queue Storage, Service Bus), event streaming (Event Hubs), event distribution (Event Grid).
• Service Bus is the default for business workflows. Sessions for FIFO, DLQ for poison messages, Premium for high volume / VNet / geo-DR.
• Event Hubs is the default for telemetry streaming. Partition count is set at creation time; consumer groups give independent multi-tenant consumption.
• Event Grid is the default for fire-and-forget fan-out — Azure resource events, custom domain events, webhook integration.
• Queue Storage is acceptable only for low-volume / low-feature work distribution. Most production usage wants Service Bus instead.
• Don't pick one service for everything. A multi-consumer event often needs different mechanisms for different consumers.

Walk the map from need to pattern to service. The hardest questions on the exam test the pattern decision (brokered vs streaming vs distribution); below that, configuration questions about tier, partitions, and DLQ are mechanical.