What's changed: Added per-section figures (cert-figure-retrofit). New AI-200 Chapter 3 (messaging = message(command) vs event(notification), Service Bus queue/topic & dead-letter, Event Grid, event-driven AI pipeline = event→function/container→AI service, resilience = retries/idempotency/dead-letter, independent per-stage scaling)
3.1Asynchronous, Loosely Coupled Messaging
Understand messaging that connects AI back-ends in a loosely coupled, resilient way—Azure Service Bus (queues/topics) and Azure Event Grid—and how to choose between them, from a developer’s view.
An AI pipeline (ingest → embed → index → notify) that has steps call each other directly lets one step’s failure or load ripple across the whole. Messaging avoids this with asynchronous, loose coupling: the sender sends and is freed immediately, and the receiver processes at its own pace. This gives load leveling (buffering), retries on failure, and independent scaling.
3.1.1Messages (commands) vs events (notifications)
There are two broad kinds. A message conveys the sender’s intent (a command—"do this processing") to be reliably delivered and processed by a specific receiver. An event is a notification that "something happened," lightweightly delivered to any interested subscribers. The former’s flagship is Azure Service Bus; the latter’s is Azure Event Grid.
3.1.2Service Bus: queues and topics
- Queue: one-to-one. A single receiver pulls and processes each message (worker distribution).
- Topic / subscription: one-to-many. Multiple subscribers each receive a copy (fan-out).
- Delivery guarantees / ordering / dead-letter: reliable delivery, ordering, and isolating failed messages (dead-letter)—enterprise-grade reliability.
Common: (1) "reliably deliver and process commands (reliability, ordering, dead-letter)" = Azure Service Bus. (2) "lightweightly notify many that something happened" = Azure Event Grid. (3) Service Bus queue = one-to-one, topic/subscription = one-to-many (fan-out). (4) Messaging yields async, loose coupling, resilience.
Watch out: (1) message (command, reliably processed) vs event (notification, lightweight)—this drives Service Bus vs Event Grid. (2) queue (one-to-one) vs topic (one-to-many). (3) Messaging is asynchronous—different from needing immediate synchronous responses. (4) Dead-letter is not "discard" but isolating failed messages for later handling.
3.1.3Section summary
- Messaging gives async, loose coupling, resilience (load leveling, retries, independent scaling)
- Service Bus = reliably process commands (queue=1:1 / topic=1:many) / Event Grid = lightweight event notification
- Reliability: delivery guarantees, ordering, dead-letter (isolate failed messages)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which service reliably delivers commands to a receiver with reliability features like ordering and dead-letter?
Q2. Which Azure service lightweightly notifies many interested subscribers that "something happened"?
Q3. In Service Bus, what delivers a copy of one message to multiple subscribers (fan-out)?
Q4. What is a main benefit of loosely coupling an AI pipeline with messaging?
Q5. Which mechanism isolates failed messages for later investigation/reprocessing?