CH18-03: Target Architecture for APIs, Messaging, Events, and Workflows

Goal

This section sketches a target Azure architecture for enterprise integration using API mediation, workflow orchestration, reliable messaging, event routing, data synchronization, monitoring, and audit.

The previous section defined contracts. Now we can choose architecture building blocks with more discipline.

The durable idea is:

The architecture should match each integration path to the communication contract it needs.

The Short Version

A strong Azure integration architecture does not pick one integration service for every problem. It uses API Management where request-response interfaces need protection and lifecycle management. It uses Service Bus where business work must be delivered reliably. It uses Event Grid where systems need to react to state changes. It uses Event Hubs where high-volume streams must be ingested and processed. It uses Logic Apps or another workflow layer where business processes span multiple systems and steps. It uses data synchronization paths where reporting, ERP, CRM, support, or finance need shared state.

The services are important, but the decision starts with the contract, failure behavior, and owner.

Target Architecture

One practical commerce integration architecture can look like this:

flowchart TB
	A["Commerce Domains<br/>Storefront, seller, order, inventory, finance"]
	B["API Mediation<br/>Azure API Management"]
	C["Workflow Orchestration<br/>Azure Logic Apps or workflow services"]
	D["Reliable Messaging<br/>Azure Service Bus queues and topics"]
	E["Event Routing<br/>Azure Event Grid"]
	F["Streaming Ingestion<br/>Azure Event Hubs"]
	G["Enterprise and Partner Systems<br/>ERP, CRM, tax, fraud, carriers, suppliers"]
	H["Data Synchronization<br/>Reporting, support, finance, analytics"]
	I["Observability and Audit<br/>Azure Monitor, logs, traces, dashboards"]

	A --> B
	A --> C
	C --> D
	C --> E
	A --> F
	B --> G
	D --> G
	E --> H
	F --> H
	G --> H
	B --> I
	C --> I
	D --> I
	E --> I
	F --> I
	G --> I

This is a reference shape, not a mandatory blueprint. The value is in the responsibility split:

• APIs mediate controlled request-response access.

• Workflows coordinate multi-step business processes.

• Queues and topics preserve reliable work across slow or unavailable systems.

• Events announce state changes to interested consumers.

• Streams collect high-volume event data for analytics or near-real-time processing.

• Data synchronization supports reporting, finance, support, and operational views.

• Monitoring and audit sit across every path, not only at the edge.

Choosing the Pattern

Do not read this table as a rigid service map. For example, Service Bus topics and Event Grid can both look like publish-subscribe. The difference is the kind of promise. Service Bus is usually stronger for durable business messages where consumers process work and failures require dead-letter handling. Event Grid is usually better for event notification and routing where subscribers react to a state change.

Where Mediation Belongs

API mediation belongs at boundaries where consumers should not couple directly to backend implementation details.

In Azure, API Management can act as the gateway for partner-facing, internal, and developer-facing APIs. It can enforce authentication, authorization checks, quotas, rate limits, transformations, routing, and observability. It can also provide a developer portal and API lifecycle management capabilities.

For a commerce platform, this matters when sellers, marketplace partners, mobile apps, support tools, or internal applications consume APIs. The gateway should protect backend services from uncontrolled traffic and hide backend changes from consumers where possible.

Mediation should not become a dumping ground for all business logic. Use it for edge policy, protection, contract shaping, routing, and observability. Keep domain decisions in the services or workflows that own the business meaning.

Where Workflows Belong

Workflow orchestration belongs where a business process has multiple steps, waits, calls to external systems, conditional paths, and recovery behavior.

Azure Logic Apps is often useful for enterprise integration because it provides managed connectors, workflow triggers, actions, conditions, and integration capabilities across cloud, on-premises, and partner systems. It can help coordinate processes that would otherwise become scattered across point-to-point scripts or service calls.

In commerce, a workflow might coordinate seller onboarding, supplier file processing, tax document exchange, warehouse exception handling, or finance export validation. The workflow should make process state visible: where work is waiting, which external call failed, which step needs manual review, and what can be retried.

Example: Different Paths for Different Commerce Needs

Consider four integration needs:

• A seller updates product data.

• A warehouse sends stock updates.

• A carrier sends delivery events.

• Finance receives settlement data.

The seller product update might enter through API Management so the seller has a protected API with authentication, throttling, validation, and versioning. The resulting catalog update may create a message on Service Bus if downstream enrichment and approval must happen reliably.

Warehouse stock updates may arrive through messages or files depending on the warehouse system. Inventory changes may publish events to update search, product detail pages, seller dashboards, and support views.

Carrier delivery events may arrive through partner webhooks, Event Grid, or an API endpoint, then be validated, correlated, and routed to customer notification, support timeline, and delivery analytics.

Finance settlement data may be exported through a controlled workflow and data synchronization path because accuracy, reconciliation, and auditability matter more than instant response.

The architecture is not inconsistent because it uses several patterns. It is stronger because each integration path matches the contract it needs.

Common Mistakes

• Choosing one integration technology for every problem. A queue, event router, API gateway, stream, and workflow engine each solves a different kind of communication problem.

• Bypassing mediation for partner-facing APIs. Direct partner-to-service coupling makes throttling, versioning, authorization, and observability harder.

• Forgetting data synchronization and audit needs. Integration is not complete just because operational calls work; finance, support, analytics, and compliance often need traceable state movement.

• Putting all business meaning into the integration layer. Central integration should mediate and standardize, but domain teams must still own domain rules and event meaning.

If Someone Asks You

What would an Azure enterprise integration architecture include?

It would include API mediation for controlled request-response access, workflow orchestration for multi-step business processes, reliable messaging for durable commands and business messages, event routing for state-change notifications, streaming ingestion for high-volume telemetry or business signals, data synchronization for enterprise and reporting systems, and observability and audit across every boundary. The design should explain which pattern is used for which contract and who owns the result.

What You Should Remember

Match the integration pattern to the contract, failure behavior, and ownership model.

Questions to Check Your Understanding

1. When is Service Bus more appropriate than Event Grid in a commerce integration design?

2. Why might a workflow service be needed around partner or enterprise system calls?

3. What should an API mediation layer protect, and what should it avoid owning?