CH05-01: Integration Selection Mental Model

Goal

Chapter 4 helped you choose where code should run. Once those components exist, the next question is how they should communicate without becoming tangled together.

Integration selection is the architecture decision that defines communication contracts between systems. It decides whether one component is asking another component to do reliable work, announcing that something happened, publishing a high-volume stream of records, or coordinating a business process across steps and systems.

The durable idea for this chapter is:

The meaning of the message should choose the integration service.

The Short Version

The easy question is:

Which Azure messaging service should I use?

The better architecture question is:

What kind of communication am I designing?

Azure has several integration services because systems communicate for different reasons. Azure Service Bus, Azure Event Grid, Azure Event Hubs, and Azure Logic Apps all help systems connect, but they do not mean the same thing.

Do not worry about memorizing every feature yet. Start with four communication shapes:

Communication need
    |
    +-- Ask another system to do work reliably -> Command or queue
    +-- Tell interested systems something happened -> Event notification
    +-- Ingest many records over time -> Stream
    +-- Coordinate steps, connectors, and decisions -> Workflow

If you can name the communication shape, the Azure service choice becomes much clearer.

Commands

A command asks another system to do work.

Examples:

Create an order.
Reserve inventory.
Generate an invoice.
Start fulfillment.
Send a payment for processing.

Commands usually carry business intent. If the receiver is temporarily unavailable, the work should not disappear. If the receiver fails halfway through processing, the system needs retry and recovery behavior. If the same command is processed twice, the business result may be wrong.

This is why commands often need durable messaging. Azure Service Bus is commonly used for this kind of reliable work handoff.

Events

An event says something happened.

Examples:

Order created.
Payment completed.
Inventory changed.
Product image uploaded.
Resource deleted.

An event is not usually an instruction to one specific receiver. It is a fact that interested systems can react to. There may be many subscribers, one subscriber, or no subscribers. The publisher should not need to know which subscribers exist.

Azure Event Grid is commonly used for routing discrete event notifications to interested handlers.

Streams

A stream is a sequence of records over time.

Examples:

Click activity.
Device telemetry.
Application logs.
Transaction signals.
Operational metrics.

Streams are usually high-volume and time-oriented. Consumers read from the stream, track their position, and process records for analytics, monitoring, alerting, or downstream pipelines. A stream is not the same as a queue. A queue is usually about work items being processed and removed. A stream is usually about many consumers reading from a retained flow of records.

Azure Event Hubs is commonly used for high-throughput event streaming and ingestion.

Workflows

A workflow coordinates steps.

Examples:

Validate an order.
Request manual approval.
Update a CRM system.
Call a partner API.
Send a message to fulfillment.
Record the outcome for audit.

Workflow orchestration is not only message passing. It includes sequence, branching, retries, connectors, state, visibility, and business process ownership. Azure Logic Apps is commonly used when integration is about coordinating steps across services, SaaS systems, on-premises systems, approvals, and connectors.

Decision Dimensions

Use these questions before choosing a service:

Decision Dimension	What You Are Really Asking
Meaning	Is this a command, event, stream, or workflow?
Durability	Must the message be stored until a receiver can process it?
Failure behavior	What happens when a receiver fails, times out, or processes a bad message?
Fan-out	Does one message need to notify many independent consumers?
Throughput	Is this occasional business work or a large continuous flow of records?
Ordering	Does order matter, and at what scope?
Retry and idempotency	Can the same message be delivered or processed more than once safely?
Ownership	Who owns the producer, broker, consumer, schema, and failure handling?
Observability	How will the team trace one business action across asynchronous components?

These questions matter because asynchronous systems can fail quietly. If a direct API call fails, a user or calling service may notice immediately. If an event handler fails or a message sits in a dead-letter queue for three days, the business may not notice until a customer complains. Integration design must make failure visible.

Example: One Order, Several Communication Contracts

Imagine a retail platform. A customer places an order, inventory must be reserved, downstream systems need to know the order exists, the web team wants click activity for analytics, and high-value orders require approval.

These are not the same integration problem:

Scenario Moment	Communication Shape	Azure Direction
Customer submits order for fulfillment.	Command	Service Bus queue or topic.
Other systems need to know an order was created.	Event notification	Event Grid.
Website produces click and cart activity.	Stream	Event Hubs.
High-value order needs approval and partner update.	Workflow	Logic Apps.

The platform may use all four services. That is not overengineering if each path has a clear job. It becomes overengineering only when the team cannot explain why each path exists.

Common Mistakes

Treating every asynchronous interaction as the same kind of message.
Using event routing for work that must be stored until processed.
Using queues for high-volume analytics streams.
Building workflow state manually when orchestration and connectors are the real need.
Forgetting that retries can create duplicate effects unless handlers are idempotent.
Publishing large or sensitive payloads in events without thinking about coupling, privacy, and versioning.

If Someone Asks You

How do you choose between Azure messaging and integration services?

A good answer is:

I start by naming the communication contract. If a message asks a receiver to do reliable business work, I consider Service Bus. If it announces that something happened and many systems may react, I consider Event Grid. If it is a high-volume stream of telemetry or activity records, I consider Event Hubs. If the problem is coordinating business steps, connectors, approvals, and visible process history, I consider Logic Apps. Then I check durability, retries, ordering, throughput, ownership, and observability.

What You Should Remember

First name the communication contract, then choose the integration service.

Questions to Check Your Understanding

What is the difference between a command and an event?
Why is a stream not the same as a queue?
What makes workflow orchestration its own integration problem?