AZ-DEV-160: Messaging and Event-Driven Systems on Azure
Deep dive into the three pillars of async communication on Azure: Service Bus for commands and enterprise messaging, Event Grid for reactive event-driven architectures, and Event Hubs for high-throughput streaming. Cover choosing between them, advanced patterns (sessions, dead-letter, claim-check, MQTT, capture), and a capstone building a full event-driven order-processing system that uses all three services.
About This Course
Async communication is the backbone of any real distributed system, and Azure offers three complementary services Service Bus, Event Grid, and Event Hubs that many developers conflate. This course teaches when to pick which service, what advanced patterns each supports, and how to combine them in a hybrid architecture. Every lab uses the modern Azure.Messaging.* SDKs with DefaultAzureCredential.Service Bus modules cover queues (sessions, transactions, dead-letter, duplicate detection), topics and subscriptions with SQL filters, and advanced patterns like auto-forward and claim-check for large payloads. Event Grid modules cover the classic push-delivery model, the newer namespace-topic pull model, and MQTT broker integration for IoT. Event Hubs modules cover partition-based streaming, consumer groups, capture to Data Lake, and Kafka protocol compatibility.By the end you can pick the right Azure messaging service for a scenario, design Service Bus messaging with sessions and dead-letter handling, publish and subscribe to Event Grid with CloudEvents schema, use Event Grid Namespace topics for MQTT + pull-delivery, ingest high-throughput telemetry with Event Hubs partitions and consumer groups, and combine all three in a hybrid event-driven system.
Course Curriculum
20 Lessons
AZ-DEV-160 M1L1 - Messaging patterns overview - commands, events, telemetry
Three services, three patterns: Service Bus for commands, Event Grid for reactive events, Event Hubs for telemetry streams. This lesson names the semantic differences (delivery guarantees, ordering, throughput profiles, cost) and gives you a decision matrix for picking the right service.
AZ-DEV-160 M1L2 - Same use case, three services - compare Service Bus vs Event Grid vs Event Hubs - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.
Implement the same "OrderReceived" notification with all three services. Compare cost model, latency, delivery guarantees, and code shape. Produce a decision matrix documenting when to pick each.
AZ-DEV-160 M2L3 - Service Bus queues - sessions, PeekLock, dead-letter, duplicate detection
Service Bus queue mechanics: PeekLock vs ReceiveAndDelete, message locks, sessions for FIFO per key, transactions, dead-letter subqueue, duplicate detection, scheduled messages. By the end you can design an ordered per-customer processing pipeline with dead-letter handling.
AZ-DEV-160 M2L4 - Build a session-based Service Bus queue with dead-letter and duplicate detection - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.
Build an order-processing queue with SessionId=customerId FIFO ordering. Verify two orders for the same customer process sequentially while different customers process in parallel. Simulate a bad message and observe automatic dead-lettering.
AZ-DEV-160 M3L5 - Service Bus topics and subscriptions with SQL filters
Publish-subscribe with Service Bus topics + subscriptions. SQL filter rules, correlation filter rules, action rules that modify message on match, rule chaining. Multi-tenant routing patterns.
AZ-DEV-160 M3L6 - Build a multi-tenant order-routing topic with SQL filter subscriptions - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.
Create a topic with three subscriptions using SQL filter rules on message properties (Tenant='Acme', Tenant='Contoso', OrderTotal > 10000). Publish 1000 orders and verify each subscription receives only its subset.
AZ-DEV-160 M4L7 - Advanced Service Bus - auto-forward, deferral, and claim-check pattern
Advanced Service Bus patterns: auto-forward chains, message deferral for out-of-order arrival, claim-check pattern for large payloads (message contains blob URL instead of the payload), retry policies with exponential backoff.
AZ-DEV-160 M4L8 - Implement the claim-check pattern for large payloads - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.
Implement the claim-check pattern end-to-end: uploader stores a 100MB payload in Blob Storage and sends a small Service Bus message containing the blob URL. Processor reads the blob, processes it, then completes the SB message. Verify with a large payload flowing end-to-end.
AZ-DEV-160 M5L9 - Event Grid basics - CloudEvents, custom topics, and event subscriptions
Event Grid fundamentals: CloudEvents v1.0 schema, custom topics vs system topics, event subscriptions, endpoint types (webhook, Function, Service Bus, Event Hubs, Storage Queue), event filters, delivery retries + DLQ.
AZ-DEV-160 M5L10 - Build Blob-upload event pipeline via Event Grid - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.
Wire a Blob-Created event flow: Storage → Event Grid system topic → Storage Queue subscription → .NET consumer. Verify 100 blob uploads produce 100 queue messages via Event Grid delivery.
AZ-DEV-160 M6L11 - Event Grid advanced - Namespace topics, MQTT broker, and pull delivery
Event Grid Namespace topics (pull delivery, GA 2024), MQTT broker for IoT devices, MQTT-to-Event-Grid routing, subscription retries + DLQ, dead-letter reprocessing patterns.
AZ-DEV-160 M6L12 - Event Grid Namespace with pull-delivery from .NET - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 12 minutes for the environment to become ready before beginning the exercises.
Deploy an Event Grid Namespace with a namespace topic. Publish events from one .NET service; consume via pull-delivery from another .NET service. Compare with push-delivery from Module 5.
AZ-DEV-160 M7L13 - Event Hubs and streaming - partitions, consumer groups, EventProcessorClient
Event Hubs partitions and throughput units, publishers vs consumers, consumer groups, Event Processor Client, and checkpointing to Blob Storage.
AZ-DEV-160 M7L14 - Ingest telemetry with Event Hubs and process via EventProcessorClient - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.
Build a producer that emits telemetry across 4 partitions, then a consumer using EventProcessorClient with checkpointing to Blob Storage. Add a second consumer group for a parallel real-time dashboard. Verify each consumer group sees every event independently.
AZ-DEV-160 M8L15 - Event Hubs advanced - Capture to ADLS, Kafka protocol, Schema Registry
Event Hubs Capture to ADLS Gen2 in Avro, Kafka protocol compatibility, Schema Registry for Avro schemas, Event Hubs Premium tier considerations.
AZ-DEV-160 M8L16 - Enable Event Hubs Capture and produce via Kafka protocol - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.
Enable Capture on the Event Hub. Verify Avro files land in ADLS Gen2 within 5 minutes. Register schemas in Schema Registry. Connect a Kafka client via Confluent.Kafka and produce over Kafka protocol.
AZ-DEV-160 M9L17 - Choosing the right service - decision matrix and hybrid patterns
Decision matrix: latency, throughput, delivery guarantee, ordering, cost. Common hybrid architectures combining Service Bus + Event Grid + Event Hubs. Anti-patterns.
AZ-DEV-160 M9L18 - Implement three scenarios with the correct service each - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 12 minutes for the environment to become ready before beginning the exercises.
Given three business scenarios (order processing, IoT telemetry, blob upload notifications), pick the correct service for each and justify. Then implement all three, each with the right service in its right role.
AZ-DEV-160 M10L19 - End-to-end architecture review for event-driven order processing
How commands, events, and telemetry compose in a real system. Observability across three services. Failure modes and recovery. Cost model.
AZ-DEV-160 M10L20 - Ship the Anchorline event-driven order-processing capstone - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 15 minutes for the environment to become ready before beginning the exercises.
Build the end-to-end system: HTTP API → SB command → OrderProcessor → Cosmos → EG OrderCreated event → NotificationService + FulfillmentService → all emit telemetry to EH → dashboard reads EH. Verify a full order flows through in under 2 seconds with distributed tracing.