CH15-03: Target Architecture for Storefront, APIs, and Orders

Goal

The previous sections separated the commerce journey and requirements. This section turns those decisions into a practical Azure target architecture.

The durable idea is:

The target architecture should make the customer path visible without forcing every responsibility into the same runtime or data store.

The Short Version

A reasonable Azure e-commerce architecture starts with a protected public entry path, then moves through an API boundary into commerce capabilities, data stores, search, messaging, and operations.

The design should not make the storefront own everything. The storefront presents the experience. API contracts protect consumers and backends. Catalog, cart, checkout, order, notification, and tracking capabilities own business behavior. Data stores are chosen by access pattern. Messaging carries durable work after the immediate customer response. Observability, identity, security, and cost controls surround the whole platform.

A First-Pass Azure Architecture

One possible architecture looks like this:

flowchart LR
		Customer["Customers<br/><small>web and mobile</small>"]
		Seller["Sellers and Partners<br/><small>portal and APIs</small>"]
		FrontDoor["Azure Front Door + WAF<br/><small>global entry, routing, protection</small>"]
		Web["Storefront Apps<br/><small>App Service or Container Apps</small>"]
		APIM["API Management<br/><small>contracts, policies, products</small>"]
		Identity["Microsoft Entra ID / Customer Identity<br/><small>users, apps, workloads</small>"]
		Catalog["Catalog and Search APIs"]
		Cart["Cart API"]
		Checkout["Checkout and Order API"]
		Notify["Notification API / Worker"]
		CatalogData["Catalog Store + Search Index"]
		CartData["Cart Store / Cache"]
		OrderData["Order Database"]
		Bus["Service Bus<br/><small>durable order work</small>"]
		Events["Event Grid<br/><small>state-change events</small>"]
		Fulfillment["Fulfillment and Delivery Systems"]
		Monitor["Azure Monitor + Application Insights"]
		Secrets["Managed Identity + Key Vault"]

		Customer --> FrontDoor
		Seller --> FrontDoor
		FrontDoor --> Web
		FrontDoor --> APIM
		Web --> APIM
		APIM --> Identity
		APIM --> Catalog
		APIM --> Cart
		APIM --> Checkout
		Catalog --> CatalogData
		Cart --> CartData
		Checkout --> OrderData
		Checkout --> Bus
		Checkout --> Events
		Bus --> Fulfillment
		Events --> Notify
		Notify --> Customer
		Catalog --> Monitor
		Cart --> Monitor
		Checkout --> Monitor
		Bus --> Monitor
		Events --> Monitor
		Catalog --> Secrets
		Cart --> Secrets
		Checkout --> Secrets

This diagram is intentionally a teaching architecture. Real designs may use more regions, private networking, multiple environments, data replication, deployment pipelines, fraud provider integration, payment provider integration, and specialized back-office systems. The important point is that each box has a job.

Responsibility Map

Do not read this table as a mandate that every commerce platform must use every service. Read it as an example of responsibility matching.

Public Entry and API Boundary

The public entry layer answers: how do users safely reach the platform?

For an internet-facing commerce platform, Azure Front Door can provide global entry, routing, edge acceleration, TLS handling, health probes, and Web Application Firewall integration. This is useful when customers and sellers arrive from many locations and the platform needs a consistent edge.

API Management answers a different question: how do consumers safely reach backend capabilities through contracts? Web, mobile, seller, partner, and internal support consumers should not all receive the same broad backend surface. API Management can help group APIs into products, apply policies, validate credentials or tokens, enforce quotas and rate limits, transform requests or responses where appropriate, and emit gateway telemetry.

The edge protects and routes traffic. The API boundary shapes the contract.

Commerce Capabilities

The backend should be organized around business capabilities, not only technical layers.

Catalog and search capabilities serve product discovery and detail pages. Cart capabilities preserve customer intent and recalculate important values before checkout. Checkout and order capabilities validate the request, coordinate payment and fraud boundaries, create order state, and publish durable work. Notification and tracking capabilities keep customers informed without making checkout wait for every downstream operation.

These capabilities can start inside a modular application or be split across services. The architecture question is not "How many services should we have?" The better question is "Which responsibility changes, scales, fails, and is owned independently?"

Data and Search Choices

Different data has different access patterns.

Product catalog data may need fast reads, search indexes, filtering, ranking, and cached product detail views. Cart data needs low-latency updates and recovery. Order data needs durable, auditable state transitions. Notification history needs investigation and retry visibility. Operational telemetry needs queryable logs and metrics.

This is why polyglot persistence can be reasonable in commerce systems. The design may use relational storage for order records, a search index for product discovery, a cache for low-latency reads, object storage for static product media, and analytics storage for behavior and reporting. The team should choose each store because of the data model and access pattern, not because one favorite database should contain everything.

Event and Message Paths

Checkout is the key boundary.

A typical flow might be:

Checkout request
	-> authenticate customer
	-> validate cart, price, availability, and fraud signals
	-> coordinate payment authorization boundary
	-> create durable order state
	-> send order work to Service Bus
	-> publish selected state-change events
	-> return confirmation or clear pending/rejected state

Service Bus is a strong fit when downstream work must not disappear if workers are unavailable or traffic spikes. Event Grid is useful when the architecture needs to route state-change events to interested subscribers. The distinction matters: a command such as "fulfill this order" has a different reliability expectation from an event such as "order created."

Example: Checkout Without Waiting for Everything

A customer checks out during a campaign. The checkout service validates the cart, confirms current price and availability rules, coordinates the payment authorization boundary, creates an order record, and returns an order confirmation.

After that, durable messages and events continue the work: fulfillment handoff, customer email, inventory workflows, analytics, and support projections. If the notification provider is down, the order still exists. If fulfillment workers are behind, the queue depth and message age tell operations where the delay is. If a duplicate checkout request arrives, the order API uses idempotency rules so the customer does not get two orders accidentally.

This is the core pattern: keep the customer response path clear, but do not make downstream work invisible or unreliable.

Common Mistakes

• Making the storefront directly own order, fulfillment, notification, and payment integration details. The storefront should not become the entire business platform.

• Choosing services before separating responsibilities. This leads to impressive diagrams with unclear ownership.

• Forgetting API contracts for mobile, seller, partner, and internal experiences. Different consumers need different controls.

• Treating events and queues as interchangeable. Durable work and state-change notification are different communication problems.

• Putting all data in one store even when access patterns conflict.

If Someone Asks You

A reasonable Azure e-commerce architecture would use a protected edge such as Azure Front Door with WAF, an API boundary such as API Management, managed compute for storefront and backend capabilities, separate catalog, cart, checkout, order, notification, and tracking responsibilities, data stores chosen by access pattern, Service Bus for durable order work, Event Grid for appropriate state-change events, managed identity and Key Vault for secure access, and Azure Monitor with Application Insights for journey-level observability.

What You Should Remember

The architecture should expose clear customer paths and clear ownership boundaries.

Questions to Check Your Understanding

1. Why should the API layer be visible in the design?

2. Which data stores might have different access patterns?

3. Where does event-driven processing begin in the order journey?