CH11-06: Event-Driven Architecture Scenario

Goal

This chapter started with a simple event flow: source, router, handler, durable work when needed, and observability. This section puts the pieces together in one Azure architecture scenario.

The durable idea is:

A strong event-driven design explains what happened, who reacts, what work must complete, and how failures are handled.

Scenario

A media platform lets customers upload training videos. After upload, the platform needs to:

Extract metadata such as duration, format, and size.
Generate thumbnail images and preview clips.
Scan the file before publishing.
Update the content catalog and search index.
Notify the customer when processing completes or fails.
Give operations teams clear failure handling and replay options.

The upload request should stay responsive. Video processing may take time. Some work is business-critical and should not disappear if a worker is unavailable.

Architecture Sketch

One possible design is:

Customer upload
  |
  v
Blob Storage stores video
  |
  v
Event Grid routes VideoUploaded event
  |-- Metadata Function records basic properties
  |-- Processing starter validates event and queues durable work
  |-- Audit subscriber records upload event
  |
  v
Service Bus Queue: process-video
  |
  v
Container App worker generates thumbnails, previews, and scan results
  |
  +-- Updates catalog/search state
  +-- Sends completion or failure notification
  +-- Sends repeated failures to dead-letter path

Logs, metrics, traces, alerts, dashboards, and runbooks cover the flow

This is not the only valid design. It is a useful example because each service has a distinct job.

Responsibility Map

Responsibility	Azure Design Choice	Why It Fits
Store uploaded media.	Blob Storage	The video file belongs in object storage, not inside an event payload.
Announce that upload happened.	Event Grid	The upload is a fact that multiple subscribers may react to.
Handle lightweight metadata.	Azure Function	The metadata task is small, event-triggered, and focused.
Protect processing work.	Service Bus queue	Thumbnail generation and scanning must survive worker outages and spikes.
Run heavier processing.	Container Apps worker	Video tooling and processing libraries fit a containerized worker model.
Investigate repeated failures.	Service Bus dead-letter queue	Poison messages and repeated failures need an owned review path.
Trace the workflow.	Application logs, metrics, traces, and correlation IDs	Teams need to follow one upload across asynchronous components.

The design separates notification from durable work. Event Grid tells the architecture that a video was uploaded. Service Bus carries the processing work that must complete.

Event Contract

The upload event should be small and stable. It might include:

Field	Purpose
`eventType`	Names the fact, such as `VideoUploaded`.
`version`	Allows the contract to evolve.
`videoId`	Identifies the business object.
`blobUrl` or storage reference	Points handlers to the stored file.
`tenantId` or customer identifier	Helps route and authorize processing where needed.
`correlationId`	Connects upload, events, work messages, logs, and notifications.
`uploadedAt`	Records when the event occurred.

The event should not carry the video file itself. Large payloads belong in storage. The event should carry identifiers and context.

Flow Walkthrough

A customer uploads a video through the application.
The application stores the file in Blob Storage and records the upload request.
A VideoUploaded event is published or emitted from the storage event source.
Event Grid routes the event to subscribers.
A Function extracts lightweight metadata and records it with the same correlation ID.
A processing starter validates the event and creates a Service Bus message for durable video processing.
A Container Apps worker consumes the message, generates thumbnails and previews, runs scanning or classification, and records progress.
If processing succeeds, the catalog/search state is updated and the customer can be notified.
If processing fails repeatedly, the message moves to a dead-letter queue and alerts notify the owning team.

Notice the design does not make the upload service wait for video processing to finish. It also does not pretend that notification alone guarantees processing.

Failure Handling

The most important part of the design is not the happy path. It is what happens when something goes wrong.

Failure	Design Response
Event payload is invalid.	Handler rejects it, logs correlation details, and routes to an investigation path.
Metadata Function fails temporarily.	Retry within the handler's configured policy and alert if failures continue.
Processing worker is offline.	Service Bus retains messages until workers recover.
Video file is corrupt.	Worker records a business failure and notifies the customer or review team.
Processing fails repeatedly.	Message moves to dead-letter queue for owned investigation.
Duplicate event arrives.	Handlers use `videoId` and processing state to avoid duplicate side effects.
Search update fails.	Worker retries carefully or creates follow-up durable work, depending on business need.

This is why event-driven architecture is an operations design as much as a communication design.

Alternatives and Trade-Offs

This scenario could be designed differently depending on requirements.

If upload processing must complete before the user can continue, a synchronous API might be appropriate for part of the flow, though it can hurt responsiveness and reliability under load.

If processing has many visible business steps, approvals, partner calls, or human review, a workflow service such as Logic Apps or Durable Functions may be a better fit for orchestration.

If the platform needs high-volume telemetry about every processing step, Event Hubs may be useful for streaming operational events to analytics. That is a stream problem, not the same as durable video processing work.

If all processing is simple and non-critical, Event Grid plus a Function may be enough. Adding Service Bus and workers only makes sense when reliability, buffering, or operational control justify the extra moving parts.

Common Mistakes

Using events for every interaction without asking whether the communication is really a command, stream, workflow, or direct request.
Forgetting durable processing for business-critical work and relying only on notification delivery.
Putting large files or sensitive data into event payloads instead of using storage references.
Ignoring schema ownership, duplicate handling, and versioning.
Creating dead-letter queues without alerts, runbooks, or an accountable owner.
Designing the first screen of the architecture diagram but not the incident response path.

If Someone Asks You

How would you design an event-driven workflow in Azure?

A good answer is:

I would start by naming the event source and the event contract. Then I would use Event Grid to route the notification to subscribers. Lightweight reactions can run in Functions, while heavier or containerized processing can run in Container Apps. If the reaction represents work that must complete, I would put that work on Service Bus and define retries, idempotency, dead-letter handling, monitoring, ownership, and replay. I would also make correlation IDs and dashboards part of the design so the team can operate the distributed flow.

What You Should Remember

Walk from event source to routing, processing, durable work, failure handling, and observability.

Questions to Check Your Understanding

Which part of the scenario uses Event Grid?
Which part needs Service Bus and why?
How does the team detect and resolve failed processing?