CH15-06: Core E-Commerce Platform Scenario

Goal

This section applies the Chapter 15 model to a monolith-to-Azure e-commerce modernization scenario.

The goal is not to produce one perfect reference architecture. The goal is to show how a solution designer can walk from customer journey to requirements, target architecture, trade-offs, failure modes, operations, and a clear architecture conversation answer.

The durable idea is:

A strong scenario answer walks from customer journey to architecture, trade-offs, failure modes, and operations.

Scenario

A large e-commerce company is moving from a monolithic online store to an Azure platform. The business supports:

• Millions of customers.

• Web and mobile storefronts.

• Seller portals for catalog, pricing, and inventory updates.

• Partner access for selected integrations.

• Campaign and holiday traffic spikes.

• Search, product detail pages, carts, checkout, orders, notifications, and delivery tracking.

• Asynchronous order processing and fulfillment handoff.

• Customer data protection, fraud controls, observability, and cost visibility.

The current monolith handles most responsibilities in one codebase and one primary database. It works during normal traffic but becomes fragile during major campaigns. Product pages slow down, checkout depends on too many downstream calls, order status is hard to investigate, and teams struggle to know whether an incident is a frontend, database, payment, fulfillment, or notification problem.

The modernization goal is not to split everything at once. The goal is to create clearer boundaries and protect the customer journey.

Step 1: Start with the Journey

Before naming Azure services, explain the journey:

Customer browses or searches
	-> views product detail
	-> adds item to cart
	-> checks out
	-> receives order confirmation
	-> downstream fulfillment and notification continue
	-> customer tracks delivery or contacts support

Then name the design priorities:

This prevents the common weak answer: "Use Azure Front Door, App Service, Cosmos DB, and Service Bus." Service names are useful, but only after the requirements are organized.

Step 2: Choose a First-Pass Target Design

A reasonable first-pass target architecture might look like this:

flowchart LR
		Users["Customers, Sellers, Partners"]
		Edge["Azure Front Door + WAF"]
		Storefront["Storefront Apps<br/><small>web and mobile experience</small>"]
		Gateway["API Management<br/><small>contracts, policies, routing</small>"]
		Catalog["Catalog/Search Capability"]
		Cart["Cart Capability"]
		Checkout["Checkout and Order Capability"]
		Notify["Notification and Tracking"]
		Search["Search Index / Read Models"]
		CartStore["Cart Store / Cache"]
		Orders["Order Database"]
		Bus["Service Bus<br/><small>fulfillment and durable work</small>"]
		Events["Event Grid<br/><small>state-change routing</small>"]
		Fulfillment["Fulfillment, Inventory, Delivery"]
		Ops["Azure Monitor, App Insights, dashboards"]
		Security["Identity, Managed Identity, Key Vault"]

		Users --> Edge
		Edge --> Storefront
		Edge --> Gateway
		Storefront --> Gateway
		Gateway --> Catalog
		Gateway --> Cart
		Gateway --> Checkout
		Gateway --> Notify
		Catalog --> Search
		Cart --> CartStore
		Checkout --> Orders
		Checkout --> Bus
		Checkout --> Events
		Bus --> Fulfillment
		Events --> Notify
		Catalog --> Ops
		Cart --> Ops
		Checkout --> Ops
		Notify --> Ops
		Bus --> Ops
		Gateway --> Security
		Catalog --> Security
		Cart --> Security
		Checkout --> Security

This design separates the customer path from operational work. It also gives teams places to attach controls: edge protection, API policies, identity, data ownership, messaging, monitoring, and cost reporting.

Step 3: Explain the Main Decisions

Edge and API Boundary

Use Azure Front Door with Web Application Firewall for internet entry, global routing, health-based origin routing, TLS handling, and edge protection. Put API Management behind or alongside the entry path to publish APIs, apply policies, group APIs by consumer, rate-limit partner access, validate credentials or tokens, and collect gateway telemetry.

The key decision is that web, mobile, seller, partner, and support consumers should not call backend services directly.

Compute Boundaries

Use managed hosting such as App Service or Container Apps for storefronts and commerce APIs unless the team has a clear reason to operate Kubernetes. Container Apps can fit containerized services and workers. App Service can fit managed web and API hosting. AKS might be justified later if the organization needs Kubernetes control, ecosystem integration, or a platform standard, but it should not be the default answer simply because the workload is important.

The key decision is to separate responsibilities before choosing runtime complexity.

Data Boundaries

Use data stores by access pattern. Product discovery may need search indexes and read models. Cart state may need low-latency session continuity. Order state needs durable records and support visibility. Static product images belong in object storage. Operational logs belong in monitoring and analytics systems.

The key decision is not one database versus many databases. It is whether the data model, consistency need, query pattern, and owner are clear.

Order Processing Boundary

Keep checkout validation and durable order creation in the request path. Move fulfillment handoff, notifications, analytics, and projections to asynchronous processing. Use Service Bus for durable work that must complete, with retries, dead-letter handling, idempotency, and owners. Use Event Grid where state-change event routing fits.

The key decision is to protect checkout without losing downstream work.

Step 4: Define the Migration Path

The safest modernization path is usually incremental.

1. Put the monolith behind a protected edge and API boundary where appropriate.

2. Improve observability around the existing customer journey.

3. Extract read-heavy catalog and search paths first if they are clear bottlenecks.

4. Separate cart and checkout logic carefully because they affect customer trust.

5. Introduce durable order messages for fulfillment and notification work.

6. Build operational dashboards for checkout, order processing, notification, and support visibility.

7. Continue splitting capabilities only where ownership, scale, failure isolation, or delivery speed justify it.

This path avoids a big-bang rewrite. It lets the company protect customer outcomes while learning where boundaries actually belong.

Step 5: Discuss Trade-Offs

A strong scenario answer includes these trade-offs. It does not pretend that architecture choices are free.

Step 6: Walk Through Failure Modes

Traffic Spike

Use edge caching, autoscaling, API throttling, queue buffering, and graceful degradation. Protect checkout and order creation before optional features such as recommendations or reviews.

Payment Timeout

Do not blindly retry in a way that risks duplicate authorization or unclear order state. Record a pending or failed state, use provider correlation, and provide customer/support visibility.

Duplicate Checkout Attempt

Use idempotency keys or equivalent order request tracking. The same customer action should return a known outcome instead of creating duplicate orders.

Search Outage

Fallback to cached popular products, category pages, or simplified discovery where possible. Keep checkout independent from search availability.

Notification Delay

Do not roll back a valid order because email is delayed. Retry notification, expose order status in the customer account, and alert owners if delay crosses a threshold.

Fraud Spike

Adjust risk controls, rate limits, and review paths. Make sure fraud decisions are observable and auditable, especially when legitimate customers may be affected.

Architecture Conversation Answer Structure

For an architecture conversation or design review, use this shape:

1. Start with the customer journey and critical requirements.

2. Define public entry and API contract boundaries.

3. Separate core capabilities: catalog/search, cart, checkout/order, notification/tracking.

4. Choose data stores by access pattern and consistency need.

5. Keep checkout correctness synchronous and move downstream work to durable asynchronous processing.

6. Add reliability, security, fraud, privacy, observability, and cost controls.

7. Explain trade-offs and failure modes.

8. Describe an incremental migration path from the monolith.

This structure shows architectural thinking. It also gives the listener places to ask follow-up questions.

Common Mistakes

• Jumping straight to a service list without explaining requirements.

• Ignoring the migration path from monolith to platform.

• Splitting services before identifying ownership and failure boundaries.

• Forgetting payment, fraud, idempotency, observability, and graceful degradation.

• Treating asynchronous processing as background work with no durable state or owner.

• Designing for normal traffic only and discovering campaign behavior in production.

If Someone Asks You

I would design the platform around the customer journey. Azure Front Door with WAF can protect and route public traffic, API Management can expose governed API contracts, managed compute can host storefront and commerce capabilities, and separate data stores or read models can support catalog, search, cart, and order access patterns. Checkout should synchronously validate the customer, cart, price, fraud and payment boundary, and create durable order state. Fulfillment, notification, analytics, and projections can continue asynchronously through durable messaging and event routing. I would add managed identity, Key Vault, monitoring, correlation IDs, dashboards, cost controls, graceful degradation, and an incremental migration path from the monolith.

What You Should Remember

In scenario answers, explain the journey, the boundaries, the trade-offs, and how the design behaves when things go wrong.

Questions to Check Your Understanding

1. What are the main architecture boundaries in the scenario?

2. Which risks should be discussed before the design is considered complete?

3. How would you explain the design in two minutes?