CH15-01: Core E-Commerce Platform Mental Model

Goal

Core e-commerce architecture is the design of customer journeys with different latency, consistency, reliability, and ownership needs.

It is tempting to describe an e-commerce platform as a website with a database. That picture is useful for a first demo, but it collapses too many responsibilities into one shape. A customer browsing products, a customer checking out, a seller updating catalog data, a warehouse receiving an order, and a support agent investigating delivery status are not using the same path in the same way.

The durable idea for this section is:

The customer journey is the first architecture diagram.

The Short Version

A large e-commerce platform is not one big request path. It is a set of journeys that share a business domain but differ in speed, correctness, failure tolerance, and operational ownership.

Browsing needs speed and scale. Search needs relevance and fast reads. Product detail pages need current enough information, but not every supporting feature must be perfect. Cart needs continuity so the customer does not lose intent. Checkout needs stronger correctness because money, fraud, inventory promises, and order state meet there. Order confirmation needs durable evidence. Fulfillment handoff and notifications can often continue asynchronously after the customer receives a response.

This is why the architecture should start with journeys before service names. Azure Front Door, API Management, App Service, Container Apps, Azure SQL Database, Cosmos DB, Azure AI Search, Service Bus, Event Grid, Azure Monitor, and other services may all be useful. But they are answers to responsibility questions, not the starting point.

Journey First, Services Second

Think of the platform as a flow of customer and business intent:

Customer journey
  -> Browse and search
  -> Product detail
  -> Cart
  -> Checkout
  -> Order confirmation
  -> Fulfillment handoff
  -> Notification and tracking

Each step asks a different architecture question.

The important point is not that every company uses exactly these boundaries. The important point is that the design must make the differences visible.

The Responsibility Model

A simple responsibility model for the core platform looks like this:

flowchart LR
    Entry["Public Entry<br/><small>web, mobile, seller, partner</small>"]
    API["API Boundary<br/><small>contracts, policies, routing</small>"]
    Commerce["Commerce Capabilities<br/><small>catalog, cart, checkout, orders</small>"]
    Data["Data and Search<br/><small>profiles, catalog, carts, orders, indexes</small>"]
    Async["Asynchronous Work<br/><small>events, queues, fulfillment, notification</small>"]
    Ops["Operations<br/><small>health, security, fraud, cost, ownership</small>"]

    Entry --> API --> Commerce --> Data
    Commerce --> Async
    Commerce --> Ops
    Data --> Ops
    Async --> Ops

This diagram deliberately avoids making one component the hero. The architecture is the set of responsibilities and the paths between them.

Public entry points handle customers and partners coming from the internet. The API boundary shapes how web, mobile, seller, and partner experiences call backend capabilities. Commerce services own business behavior such as catalog, cart, checkout, and order state. Data stores and search indexes support different access patterns. Asynchronous work protects the customer request path from long-running fulfillment, notification, and integration tasks. Operations makes the whole system observable, secure, recoverable, and cost-aware.

Ownership Boundaries

The journey model also helps with ownership.

A catalog team may own product data and search behavior. A checkout team may own cart validation, order creation, and payment boundary coordination. A fulfillment team may own warehouse handoff and delivery promises. A customer communication team may own notifications. A platform team may own edge routing, API gateway standards, observability, shared identity patterns, and deployment guardrails.

If those responsibilities are hidden inside one application, the organization can still run the platform for a while, but changes become risky. A promotion change can break checkout. A search incident can look like a full site outage. A notification failure can trigger repeated customer support tickets because no one can see whether orders were created correctly.

Good architecture does not require every responsibility to become a microservice on day one. It does require the design to know which responsibility is being protected and who owns it.

Example: Holiday Campaign Journey

Imagine a customer during a holiday campaign.

The customer searches for a popular product, opens the product detail page, adds the item to the cart, checks out, receives confirmation, and later tracks delivery. This looks like one shopping session, but the architecture sees several different needs.

Search must handle high read traffic and return useful results quickly. Product detail needs the latest available price, promotion, and inventory signal, but it might degrade by hiding recommendations or reviews if those dependencies are slow. Cart must preserve the customer's intent and recalculate price or availability before checkout. Checkout must validate the order, handle fraud and payment boundaries, create durable order state, and return a clear outcome. Fulfillment handoff and notifications should not make the customer wait for every warehouse, carrier, analytics, and email step.

The platform succeeds when the customer receives a correct order confirmation and the downstream work has a durable path. It does not succeed merely because the first web request returned fast.

Common Mistakes

• Treating every action as a synchronous web request. This makes checkout and downstream operations slower and more fragile than they need to be.

• Hiding order, payment, fraud, and fulfillment responsibilities inside one application boundary. This makes ownership and incident response unclear.

• Scaling only the front end. Campaign traffic often exposes bottlenecks in catalog reads, search, cart state, checkout dependencies, queues, databases, or logging pipelines.

• Starting with a service list. Service choices are useful only after the journey, responsibility, and failure impact are clear.

• Ignoring customer-visible failure modes. The platform needs to know what customers see when search is slow, payment times out, notification fails, or fulfillment is delayed.

If Someone Asks You

I would start by mapping the customer journey: browse, search, product detail, cart, checkout, order confirmation, fulfillment handoff, notification, and tracking. Then I would separate each path by latency, consistency, reliability, security, and ownership needs. Only after that would I choose Azure services for edge entry, API contracts, compute, data, search, messaging, monitoring, and operations.

What You Should Remember

Start with the customer journey, then split the architecture by responsibility and failure impact.

Questions to Check Your Understanding

1. Which e-commerce journeys have the strictest latency expectations?

2. Which flows can continue after the customer receives a response?

3. Why is the customer journey a useful architecture map?