Azure Architecture Guide

CH21-10: Integration, Messaging, and Workflow Orchestration

Goal

Help readers connect integration, messaging, and workflow concerns to Azure solution options, useful patterns, trade-offs, and decision prompts.

The Short Version

Integration design starts by naming the communication contract: command, event, stream, workflow, or API.

Many integration problems become confusing because every communication path is treated as a generic call between systems. Azure has different services for different communication meanings. The first decision is whether the system is asking another system to do work, announcing that something happened, streaming records, coordinating a long-running process, or exposing a stable API contract.

Concern

Systems must communicate across services, applications, partners, and business processes without becoming tightly coupled or unreliable.

Typical Symptoms

  • Every integration is treated as an API call.

  • Messages disappear or duplicate side effects occur during retries.

  • Business workflows are hidden across many services with no visible state.

  • Event notifications are used for work that must be guaranteed.

  • Partner and SaaS integrations lack monitoring and ownership.

Azure Solution Options

  • API Management for API boundary controls.

  • Service Bus for durable commands, queues, topics, and reliable processing.

  • Event Grid for event notification and routing.

  • Event Hubs for high-throughput streaming ingestion.

  • Logic Apps for workflow orchestration, connectors, approvals, and integration processes.

  • Functions or Container Apps for integration processing where appropriate.

Useful Patterns

  • Publisher-Subscriber.

  • Queue-Based Load Leveling.

  • Competing Consumers.

  • Pipes and Filters.

  • Saga.

  • Gateway Routing.

  • Gateway Aggregation.

Trade-Offs

  • APIs are direct and simple but can create runtime coupling.

  • Queues improve durability but introduce asynchronous state and backlog operations.

  • Events reduce publisher knowledge of subscribers but require contract ownership.

  • Workflows improve visibility but add orchestration ownership and cost.

Decision Prompt

Is this communication asking for work, announcing a fact, streaming records, coordinating a process, or exposing a contract?

Common Mistakes

  • Treating Service Bus, Event Grid, Event Hubs, and Logic Apps as interchangeable.

  • Building all workflows manually in code when orchestration is the real concern.

  • Forgetting idempotency, dead-letter handling, replay, and monitoring.

  • Hiding partner integration failures from operations teams.

If Someone Asks You

How do you choose Azure integration options?

I choose based on communication meaning. API Management helps expose and govern APIs. Service Bus fits durable commands and reliable processing. Event Grid routes event notifications. Event Hubs ingests high-volume streams. Logic Apps coordinates workflows and connectors. Functions or Container Apps run custom integration logic. Then I design idempotency, dead-letter handling, replay, monitoring, contract ownership, and partner-operation support.

What You Should Remember

Communication meaning chooses the integration pattern.

Questions to Check Your Understanding

  1. What distinguishes a command from an event?

  2. When does workflow orchestration help?

  3. Why does durable messaging require dead-letter and replay planning?