CH15-02: Customer Journeys, Requirements, and Constraints
Goal
The previous section used the customer journey as the first architecture diagram. This section turns that journey into practical requirements.
The durable idea is:
Requirements become clearer when each journey names its own consistency, latency, scale, privacy, and failure expectations.
The Short Version
Do not gather e-commerce requirements as one flat list. A statement like "the platform must be scalable, secure, and reliable" is true, but it does not tell a team what to build.
The better question is: scalable, secure, and reliable for which journey?
Browse and search need read scale and low latency. Cart needs continuity and recovery. Checkout needs correctness, fraud checks, payment boundary discipline, and clear order state. Order events need durability and idempotency. Notifications need retry and customer visibility. Seller and partner paths need contract boundaries and access control. Support paths need enough evidence to investigate what happened.
These requirements are connected, but they should not be treated as identical.
Journey Requirements
Use the journey to organize the first requirement pass.
| Journey | Primary Requirements | Important Constraint |
|---|---|---|
| Browse and search | Low latency, high read scale, useful ranking, cache-friendly data, graceful degradation. | Results can be fast and slightly stale, but they should not mislead customers about critical checkout facts. |
| Product detail | Price, promotion, availability, images, content, reviews, recommendations. | Supporting features can degrade, but core product and purchase information must remain trustworthy. |
| Cart | Session continuity, device transition, item state, price recalculation, recovery. | Cart state is intent, not final order truth. Checkout must revalidate. |
| Checkout | Identity, cart validation, price, payment boundary, fraud signals, inventory promise, order creation. | The response must be clear: created, rejected, pending, or recoverable. |
| Order status | Durable order state, customer visibility, support visibility, status transitions. | Customers and support teams need the same truth, even when downstream work is delayed. |
| Notifications | Email, SMS, push, support messages, retries, opt-in rules. | Notification failure should not erase the order or hide operational problems. |
| Delivery tracking | Fulfillment state, carrier updates, exception visibility, customer messaging. | Tracking may be eventually consistent, but it must not contradict order state. |
This table is not a final design. It is a way to prevent the design from using the same technical answer for every customer action.
Traffic and Scale Constraints
Large commerce systems rarely receive traffic evenly. Campaigns, holidays, product launches, influencer mentions, and limited-time offers can create sudden read-heavy bursts. The platform must protect the journeys that matter most during those bursts.
For example, a flash sale may drive ten times normal product-page traffic. A strong design does not promise that every optional feature stays perfect. It decides what must remain available and what can degrade.
| Feature | During a Spike | Possible Degradation |
|---|---|---|
| Home and campaign pages | Should stay reachable. | Serve cached or simplified content. |
| Search and product detail | Should stay fast enough to shop. | Reduce personalization, hide slow facets, or use cached read models. |
| Recommendations | Useful but not critical. | Return fallback recommendations or omit the panel. |
| Reviews | Useful but not critical for checkout correctness. | Show cached summaries or temporarily hide details. |
| Cart and checkout | Must be protected. | Limit optional cross-sells and noncritical calls. |
| Order confirmation | Must be durable and clear. | Downstream notification can retry asynchronously. |
This is an architecture decision, not only a user-interface decision. The backend must support the degradation plan. If the product page cannot load without recommendations, recommendations are no longer optional.
Correctness and Consistency
Commerce platforms mix different consistency needs.
Catalog browsing can often tolerate slight delay. Search indexes may lag behind the authoritative catalog store. Recommendations can be eventually updated. Analytics can process later. Notifications can retry.
Checkout is different. The platform must avoid creating confusing or duplicate orders, charging incorrectly, promising impossible inventory, or losing the evidence of what the customer attempted. That does not mean every downstream step must be synchronous. It means the synchronous part of checkout must define the order decision clearly and durably.
A helpful split is:
Can be read-optimized or eventually updated:
catalog views, search indexes, recommendations, analytics, tracking projections
Needs stronger correctness:
cart revalidation, payment authorization boundary, order creation, customer confirmation
Needs durable asynchronous processing:
fulfillment handoff, notification, inventory workflows, analytics, support updatesThis distinction protects both customer experience and system reliability. A slow notification provider should not make checkout fail after the order was safely created. A payment timeout should not be treated as success without follow-up state and reconciliation.
Security, Fraud, and Privacy Constraints
Security is not one checkbox near the end of the design. Different commerce journeys expose different risks.
Public browsing needs edge protection, bot and abuse awareness, rate limiting, and monitoring. Account and profile paths need customer identity and authorization. Checkout needs fraud signals, payment boundary control, data protection, and careful logging. Seller and partner paths need contract-based access and auditability. Support paths need privileged access controls because support users may see sensitive customer and order information.
The design should ask:
Which data is customer personal data?
Which actions can change money, inventory, or order state?
Which APIs are public, partner-facing, seller-facing, or internal?
Which logs could accidentally contain sensitive data?
Which roles can view or change order, payment, refund, or support information?
Azure service names help implement these controls, but the control objective comes first. Microsoft Entra ID, managed identities, Key Vault, API Management policies, Web Application Firewall, private networking, Azure Monitor, and security monitoring all support different parts of the answer.
Observability and Ownership Requirements
A requirement is incomplete if no one can operate it.
For each journey, define the signal that proves health:
| Journey | Useful Health Signals |
|---|---|
| Browse/search | Request volume, latency, search errors, cache hit rate, empty results, dependency latency. |
| Cart | Cart update failures, abandoned carts after errors, session recovery failures, price recalculation errors. |
| Checkout | Validation failures, payment timeouts, order creation latency, duplicate attempts, fraud decision outcomes. |
| Order processing | Queue depth, message age, retries, dead-letter counts, worker failures, fulfillment status delay. |
| Notifications | Send attempts, failures, retries, customer communication delay, provider errors. |
| Support visibility | Order lookup latency, missing status, conflicting states, privileged access events. |
This makes ownership visible. If checkout latency crosses a threshold, who responds? If order messages are stuck, who investigates? If notification retries are growing, who decides whether customers should see a banner or support notice?
Example: Flash Sale Requirements
During a flash sale, the platform might decide:
Campaign and product pages can serve cached content.
Recommendations and reviews may degrade.
Search must remain usable, even if ranking becomes less personalized.
Cart must preserve customer intent.
Checkout must revalidate price, availability, and payment state.
Order creation must be durable before confirmation.
Fulfillment, analytics, and notification can continue asynchronously.
Operators need dashboards for checkout success rate, queue age, payment failures, and order delay.
That is a much stronger requirement set than "handle high traffic." It tells the design what to protect.
Common Mistakes
Treating all requirements as equally critical. This makes the platform expensive, confusing, and still fragile in the wrong places.
Optimizing catalog browsing and checkout with the same consistency model. Fast reads and financial/order correctness need different treatment.
Forgetting nonfunctional requirements until after service selection. Reliability, security, observability, privacy, and cost shape service choice.
Assuming graceful degradation happens automatically. The application, API, data, and dependency design must support it.
Ignoring ownership. A dashboard without an owner is decoration.
If Someone Asks You
The most important requirements in a core commerce platform are journey-specific. Browse and search need low-latency scale. Product detail needs trustworthy purchase information. Cart needs continuity. Checkout needs correctness around identity, price, payment, fraud, inventory promise, and order state. Order processing and notifications need durable asynchronous paths, retries, observability, and clear ownership.
What You Should Remember
Requirements should be grouped by journey, not dumped into one platform-wide list.
Questions to Check Your Understanding
Which requirements matter most during checkout?
What can degrade during a traffic spike without losing the customer journey?
Why should fraud and privacy be part of architecture requirements?