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.2Event-Driven AI Pipelines and AI Service Integration
Understand building event-driven AI pipelines by combining messaging, functions, and containers, integrating Azure OpenAI / Azure AI services in a loosely coupled way, and designing for resilience (retries, idempotency).
Combining the previous building blocks yields an event-driven AI pipeline. A typical example: a document lands in storage → an event (Event Grid) fires → a function/container starts and generates embeddings → stores them in a vector store (Chapter 1) → signals completion to the next stage via a message (Service Bus). Each stage is loosely coupled and scales independently via KEDA (Chapter 2). AI services (Azure OpenAI, Azure AI services) are integrated by calling them from each stage.
3.2.1Designing for resilience
In a distributed, async pipeline, failure is expected. AI calls can fail from rate limits (quota) or transient errors, so design retries (exponential backoff) and idempotency so that re-processing the same item does not corrupt results. Route the unrecoverable to dead-letter for visibility. The result is a resilient pipeline where partial failures do not break the whole.
Common: (1) "start processing on an event like a document arriving" = event-driven (Event Grid → function/container). (2) integrate AI services (Azure OpenAI/AI services) by calling them from each stage, keeping loose coupling. (3) handle AI-call failures with retries (exponential backoff) + idempotency; route unrecoverable to dead-letter. (4) each stage scales independently via KEDA.
Watch out: (1) event-driven (loose, async) vs direct synchronous calls—do not confuse. (2) Without idempotency, retries cause double-processing side effects—design it in. (3) AI-call failures are expected, not exceptional (rate limits, etc.). (4) Each stage scales independently—grow only the bottleneck stage.
3.2.2Section summary
- Event-driven pipeline: event → function/container → AI service → next; loosely coupled, independently scaled (KEDA)
- Integrate AI services (Azure OpenAI/AI services) by calling them from each stage
- Resilience: retries (backoff) + idempotency + dead-letter (failure is expected)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. What is the design of starting downstream processing when a document arrives in storage called?
Q2. In a pipeline where AI calls can fail (transient/rate limit), which concept keeps results correct under retries?
Q3. How should you handle Azure OpenAI / Azure AI services in an event-driven AI pipeline?
Q4. Which is appropriate for resilience in a distributed async AI pipeline?
Q5. How should each stage of an event-driven pipeline scale with load?