CH18-06: Enterprise Integration in E-Commerce Scenario

Goal

This section applies the chapter model to connecting storefront services, seller systems, warehouse systems, tax providers, payment providers, fraud services, shipping carriers, ERP, CRM, finance reporting, and customer support tools.

The earlier sections taught the mental model, contracts, target architecture, boundary controls, and operating model. This final section turns those ideas into a complete scenario answer.

The durable idea is:

A strong integration scenario answer ties every connection to a business outcome, contract, failure path, and owner.

Scenario

An e-commerce company has grown from a single storefront into a marketplace-style commerce ecosystem. It now needs to connect:

• Storefront and mobile checkout.

• Seller onboarding and seller catalog tools.

• Warehouse and inventory systems.

• Tax, fraud, payment, and shipping providers.

• ERP, CRM, finance reporting, and customer support tools.

• Supplier feeds and carrier tracking events.

The company has a familiar set of problems. Some integrations are too synchronous and make checkout fragile. Some partner connections are point-to-point and hard to monitor. Schema changes break consumers. Finance does not always trust exported settlement data. Support cannot see enough order and shipment history. Operators do not have a clear replay process when partner messages fail.

The goal is to design enterprise integration on Azure without turning the integration layer into an unowned bottleneck.

Target Architecture

One target architecture can look like this:

flowchart TB
	A["Storefront and Mobile App"]
	B["Seller Portal and Partner Apps"]
	C["Commerce Domains<br/>Order, catalog, inventory, payment, support"]
	D["API Mediation<br/>Azure API Management"]
	E["Workflow Orchestration<br/>Azure Logic Apps or domain workflows"]
	F["Reliable Messaging<br/>Azure Service Bus"]
	G["Event Routing<br/>Azure Event Grid"]
	H["Streaming Ingestion<br/>Azure Event Hubs"]
	I["Partner Systems<br/>Tax, fraud, payment, carriers, suppliers"]
	J["Enterprise Systems<br/>ERP, CRM, finance, warehouse, support"]
	K["Data Sync and Reporting<br/>Operational views, analytics, reconciliation"]
	L["Security, Monitoring, Audit, Ownership<br/>Key Vault, identity, Azure Monitor, runbooks"]

	A --> C
	B --> D
	D --> C
	C --> E
	E --> F
	E --> I
	C --> G
	C --> H
	F --> J
	G --> J
	H --> K
	I --> K
	J --> K
	D --> L
	E --> L
	F --> L
	G --> L
	H --> L
	I --> L
	J --> L

This architecture is deliberately layered around responsibilities:

• API Management protects APIs exposed to sellers, partners, internal applications, and support tools.

• Workflow orchestration coordinates multi-step processes that include external systems, waits, approvals, or compensating actions.

• Service Bus carries durable commands and business messages that should not be lost when systems are slow or temporarily unavailable.

• Event Grid routes state-change events to subscribers that need to react.

• Event Hubs ingests high-volume streams such as clickstream, operational telemetry, fraud signals, or partner event streams when stream processing is needed.

• Data synchronization paths feed ERP, CRM, finance, support, analytics, and reconciliation views.

• Security, monitoring, audit, and ownership apply across every integration path.

Mapping Integrations to Patterns

The answer becomes stronger when each integration is tied to a business outcome. Do not say "use Service Bus" in isolation. Say "warehouse release should use durable messaging because paid orders must not be lost if the warehouse system is slow, and the consumer must be idempotent so replay does not duplicate work."

Request and Event Flows

Checkout Flow

Checkout stays careful about what must happen synchronously.

The storefront calls commerce services. Tax and fraud decisions may involve protected APIs and workflow logic with clear timeout behavior. Payment authorization follows the payment architecture from the next chapter's concern area, but the integration layer still needs correlation, audit, and controlled failure behavior. After the customer receives confirmation, downstream fulfillment, ERP, CRM, support, and finance updates can continue through durable messages, events, and data sync.

The design should avoid making checkout wait for every enterprise system. A customer should not be blocked because a CRM sync is slow.

Fulfillment Flow

After an order is ready for fulfillment, the order domain publishes or sends a durable command for warehouse release. The warehouse system processes the request and sends status updates. Carrier booking is coordinated through a workflow or integration process that respects partner limits. Tracking events update customer notifications, support views, and operational analytics.

This path needs idempotency, replay, dead-letter handling, and clear ownership because failures directly affect customer delivery promises.

Finance and Reporting Flow

Finance does not need every click or every transient status. It needs accurate order, invoice, refund, settlement, tax, and reconciliation data. Those paths should be versioned, auditable, and reconcilable. They may use messages, files, or data pipelines depending on the enterprise systems involved.

Finance integration should prioritize correctness, lineage, and evidence over speed.

Risk and Control Table

Operating Model

The operating model should be part of the architecture answer.

Central integration owns shared platform capabilities: API gateway standards, messaging namespaces, workflow platform patterns, monitoring conventions, security guardrails, partner onboarding templates, and reusable runbook patterns.

Domain teams own the business meaning of their contracts. The order team owns order lifecycle events. Inventory owns availability and reservation semantics. Fulfillment owns warehouse release and shipment readiness. Finance owns settlement and reconciliation meanings. Support owns support-facing customer timeline requirements.

Security and compliance define identity, data classification, secret handling, audit, privacy, and retention requirements. Operations or SRE teams coordinate incident response and service health, but they need domain owners available for business decisions.

Two-Minute Scenario Answer

If asked to design enterprise integration for this platform, you can structure the answer like this:

1. Start with business outcomes: checkout, seller onboarding, fulfillment, shipping, support, ERP, CRM, finance, and suppliers.

2. Define contracts: API, message, event, file, stream, or data sync, with owners and failure behavior.

3. Place the patterns: API Management for mediated APIs, Service Bus for durable commands and messages, Event Grid for event routing, Event Hubs for high-volume streams, Logic Apps or workflows for multi-step integration, and data pipelines for synchronization and reporting.

4. Add boundary controls: authentication, authorization, throttling, validation, schema versioning, retries, dead letters, replay, and idempotency.

5. Add operations: correlation IDs, Azure Monitor telemetry, dashboards, audit evidence, runbooks, ownership, and escalation paths.

6. Tie everything back to customer, seller, inventory, payment, delivery, support, and finance outcomes.

That answer shows architecture thinking. It explains why each integration path exists and how it survives change and failure.

Common Mistakes

• Listing integration services without explaining why each path uses one. Service names are not the design; contract and failure behavior drive the design.

• Ignoring contract versioning and partner throttling. These are not edge cases in enterprise commerce. They are normal operating conditions.

• Forgetting support, replay, audit, and ownership. A design that cannot be investigated or recovered is incomplete.

• Making checkout depend on every downstream system. Customer-facing request paths should be protected from slow enterprise processes when the business allows it.

If Someone Asks You

Design enterprise integration for a large Azure e-commerce platform.

I would start by mapping each integration to a business outcome: checkout, seller onboarding, fulfillment, shipping, finance, support, ERP, CRM, and supplier coordination. Then I would define the contract type and owner for each path. On Azure, I would use API Management for protected APIs, Service Bus for durable commands and business messages, Event Grid for state-change event routing, Event Hubs for high-volume streams, Logic Apps or workflow services for multi-step processes, and data synchronization for ERP, CRM, support, finance, and analytics. Around every path I would add identity, authorization, throttling, schema versioning, retries, dead-letter handling, replay, idempotency, monitoring, audit evidence, and clear ownership.

What You Should Remember

Integration architecture is business communication with contracts, controls, and recovery paths.

Questions to Check Your Understanding

1. Which integrations in this scenario need durable messaging, and why?

2. Which integrations need API mediation, and what should the mediation layer protect?

3. How would you explain this integration design in two minutes without simply listing Azure services?