CH05-06: Integration Choice Scenario

Goal

This section applies the Chapter 5 integration model to a realistic order-processing platform.

The goal is not to produce the only possible integration architecture. The goal is to show how a team can classify communication paths before naming Azure services.

The durable idea is:

A good integration design gives each communication path the right contract and failure behavior.

Scenario

A retail platform needs to process orders, notify downstream systems, ingest customer activity, and coordinate exception workflows.

The platform has these requirements:

Customers place orders through a web or mobile experience.
Accepted orders must be processed reliably.
Inventory, billing, fulfillment, and customer service systems need to react to order changes.
Customer click activity and operational telemetry arrive at high volume.
High-value or suspicious orders need approval before fulfillment.
Some partner and internal systems are reached through connectors or APIs.
Operations teams need visibility into failures, retries, and stuck work.

The design challenge is not choosing one integration service for everything. A strong design names the communication contract for each path.

Restating the Architecture Problem

Translate the scenario into communication questions:

Communication Path	Question to Ask
Accepted order processing	Is this reliable work that must be stored until processed?
Order-created notification	Do several systems need to know that something happened?
Inventory or fulfillment command	Does a specific downstream operation need durable processing?
Customer activity	Is this a high-volume flow of records for analytics or detection?
Exception approval	Is this a process with steps, decisions, connectors, and visible history?
Partner update	Is this a workflow step, durable command, API call, or event notification?

These questions prevent the design from turning into a product checklist.

Proposed Integration Model

One practical model is:

Checkout API
    |
    +-- Accepted order command -> Service Bus Queue or Topic
    |                              |-- Fulfillment processor
    |                              |-- Billing processor
    |
    +-- Order-created notice -> Event Grid
    |                           |-- Customer notification
    |                           |-- Audit handler
    |                           |-- Catalog or CRM reaction
    |
    +-- Customer activity and telemetry -> Event Hubs
    |                                      |-- Real-time dashboard
    |                                      |-- Fraud signal processing
    |                                      |-- Data lake capture
    |
    +-- High-value exception -> Logic Apps workflow
					     |-- Approval
					     |-- Partner or CRM update
					     |-- Service Bus command if approved

This architecture uses several integration services because the communication paths have different meanings.

Reliable Order Work

Accepted order processing is a command-style responsibility.

When the checkout API accepts an order, fulfillment and billing work should not disappear because a downstream service is temporarily unavailable. Service Bus is a strong fit for this reliable handoff.

The design might use:

A queue if one receiver group owns the work.
A topic with subscriptions if several receivers each need their own durable processing path.

For example:

Order API -> Service Bus Topic: accepted-orders
		  |-- fulfillment subscription
		  |-- billing subscription
		  |-- customer-record subscription

Each subscription needs an owner, monitoring, retry behavior, and dead-letter handling. Each consumer should be idempotent, because retries or duplicate delivery can happen.

Order Events

Some systems only need to know that an order was created or changed.

Event Grid is a good fit for notification-style reactions:

Order-created event -> Event Grid
				|-- Send customer notification
				|-- Update search or read model
				|-- Trigger audit workflow

The event is a fact. It should have a clear schema, correlation ID, and minimal payload. Consumers should not depend on private internal details from the order service.

If an event reaction becomes reliable business work, the handler can create a Service Bus message. That is a healthy combination, not a contradiction.

Customer Activity Stream

The platform also produces many customer activity records:

Page views.
Search terms.
Cart additions and removals.
Checkout attempts.
Device or session signals.
Application telemetry.

This is streaming ingestion, not command processing. Event Hubs is the better fit:

Web and mobile apps -> Event Hubs: customer-activity
				|-- Fraud analytics
				|-- Operations dashboard
				|-- Data lake capture

Consumers can read the same stream independently through consumer groups. One team may build near-real-time fraud detection. Another may store records for analytics. Another may monitor operational health.

Exception Workflow

High-value or suspicious orders need a process, not only a message.

Logic Apps can coordinate the exception flow:

Suspicious order event
	|
	v
Logic Apps workflow
	|-- Check customer history
	|-- Request manager approval
	|-- Update CRM or case system
	|-- If approved, send Service Bus fulfillment command
	|-- If rejected, notify support

The workflow provides structure and visibility. Operations can see which step failed or which approval is pending. Connectors can reduce custom glue code for email, CRM, enterprise systems, or partner APIs.

Failure Behavior Map

Each path needs failure behavior that matches its meaning.

Path	Service Direction	Failure Behavior to Design
Fulfill accepted order	Service Bus	Retries, idempotency, dead-letter queue, queue depth alerts.
Notify interested systems	Event Grid	Handler failure policy, retry expectations, dead-lettering if needed, schema ownership.
Ingest customer activity	Event Hubs	Partitioning, consumer lag, retention, replay, schema evolution, downstream processing alerts.
Approve exception	Logic Apps	Step retries, run history, connector errors, approval timeout, manual intervention.
Partner system update	Logic Apps, Service Bus, or API	Choose based on whether the update is a workflow step, durable command, or synchronous call.

This table is often more useful than a diagram in architecture reviews because it shows the operating model.

Cross-Cutting Design

Integration services need shared standards.

The platform should define:

Correlation IDs across messages, events, workflows, and logs.
Message and event schema ownership.
Retry and timeout policies.
Dead-letter ownership and response targets.
Idempotency rules for consumers.
Secrets and managed identities for service access.
Monitoring, dashboards, alerts, and runbooks.
Data classification for payloads.
Cost monitoring for high-volume streams and workflow runs.

Without these standards, asynchronous systems become hard to reason about. With them, a mixed integration architecture stays understandable.

Requirement-to-Service Map

Requirement	Integration Choice	Why It Helps
Accepted orders must be processed reliably.	Service Bus	Stores work until receivers process it and supports retry and dead-letter patterns.
Many systems need to react to order changes.	Event Grid	Routes event notifications to independent subscribers.
Customer activity arrives at high volume.	Event Hubs	Ingests streams for analytics, monitoring, and replay within retention.
Exception approvals need visible process history.	Logic Apps	Coordinates steps, connectors, decisions, and run history.
Some events start durable business work.	Event Grid plus Service Bus	Event Grid detects and routes the fact; Service Bus carries reliable processing.

The key is that every service has a communication contract. That is what makes the design explainable.

Common Mistakes

Choosing one integration service for every path.
Losing important work because notifications were used as commands.
Treating streaming telemetry like business commands.
Building approval workflow inside several disconnected functions with no process visibility.
Forgetting correlation IDs, idempotency, and dead-letter ownership.
Publishing event payloads that leak sensitive data or create tight coupling.

If Someone Asks You

How would you design Azure integration for an order-processing platform?

A good answer is:

I would classify each communication path first. Accepted orders and fulfillment commands need durable processing, so I would use Service Bus. Order-created or inventory-changed notifications can use Event Grid so interested systems can react independently. Customer activity and telemetry belong in Event Hubs because they are high-volume streams. Exception approvals and connector-heavy business processes fit Logic Apps. I would also define retries, dead-letter handling, idempotency, schema ownership, correlation IDs, monitoring, and operational ownership.

What You Should Remember

Commands, events, streams, and workflows can coexist when each path has a clear job.

Questions to Check Your Understanding

Which communication paths in the scenario should be durable commands?
Which paths are better modeled as notifications?
Why might a single order platform need both Event Grid and Service Bus?