---
title: E-commerce Scalability on AWS (2026): Cart, Checkout, Inventory, and Order Event Reference Architecture
description: For a mid-market retailer (~2.4M SKUs, checkout p95 1.9s → 420ms), DynamoDB cart + Step Functions checkout + conditional inventory cuts held 2.1k checkout RPS — after a cache-as-inventory mistake oversold 380 units in 12 minutes.
url: https://www.factualminds.com/blog/aws-ecommerce-scalability-reference-architecture-2026/
datePublished: 2026-07-10T00:00:00.000Z
dateModified: 2026-07-10T00:00:00.000Z
author: palaniappan-p
category: Cloud Architecture
tags: aws, ecommerce, retail, amazon-dynamodb, amazon-api-gateway, aws-step-functions, architecture
---

# E-commerce Scalability on AWS (2026): Cart, Checkout, Inventory, and Order Event Reference Architecture

> For a mid-market retailer (~2.4M SKUs, checkout p95 1.9s → 420ms), DynamoDB cart + Step Functions checkout + conditional inventory cuts held 2.1k checkout RPS — after a cache-as-inventory mistake oversold 380 units in 12 minutes.

**E-commerce transaction systems** fail in boring ways: cart loss, oversell, double charge, and order events that fire twice. This post is the **2026 transaction-plane reference architecture** — cart, checkout, inventory, payment handoff, order events — for teams that already have a [retail overview](/blog/aws-for-retail-complete-guide/) but need a lane map.

It is **not** [Black Friday peak tactics](/blog/aws-retail-architecture-black-friday-peak-traffic/), **not** [omnichannel analytics lakehouse](/blog/aws-retail-omnichannel-analytics-lakehouse-2026/), and **not** [SES ecommerce email](/blog/aws-ses-ecommerce-email-marketing/).

Artifacts: [lane decision matrix](https://www.factualminds.com/examples/architecture-blog-2026/ecommerce-scalability/lane-decision-matrix.md), [peak capacity worksheet](https://www.factualminds.com/examples/architecture-blog-2026/ecommerce-scalability/peak-capacity-worksheet.csv), [architecture diagram (draw.io)](https://www.factualminds.com/examples/architecture-blog-2026/ecommerce-scalability/ecommerce-scalability-reference-architecture.drawio).

> **Benchmark silhouette (not a cited client)** — **Mid-market retailer**, **~2.4M SKUs**, **~180k** daily orders (peak day **~3×**), checkout **p95 1.9s**. After moving cart to **DynamoDB**, checkout to **Step Functions**, and inventory to **conditional writes** before capture: checkout **p95 420ms**, sustained **~2.1k** checkout RPS in load test. Earlier failure: treating Redis stock counts as truth → **380** oversold units in **12 minutes** during a flash sale.

## Five lanes

| Lane                      | Default AWS path                                  |
| ------------------------- | ------------------------------------------------- |
| **Edge / catalog read**   | CloudFront + cached origins                       |
| **Session / cart**        | DynamoDB + TTL                                    |
| **Inventory reservation** | DynamoDB conditional write **or** Aurora row lock |
| **Checkout**              | Step Functions + compensation                     |
| **Orders / side effects** | EventBridge → SQS consumers (idempotent)          |

**Opinionated take:** **Reserve inventory before payment capture**, never after. Capture-first architectures create finance tickets you cannot automate away.

## Reference architecture

```
Browser ──► CloudFront ──► API Gateway ──► Cart service (DynamoDB)
                                   │
                                   ├──► Checkout (Step Functions)
                                   │         ├── reserve inventory (conditional write)
                                   │         ├── payment token / PSP
                                   │         └── write order (Aurora or DynamoDB)
                                   │
                                   └──► EventBridge (OrderPlaced)
                                              └── SQS ──► fulfillment / email / loyalty
```

Walk [lane-decision-matrix.md](https://www.factualminds.com/examples/architecture-blog-2026/ecommerce-scalability/lane-decision-matrix.md) before copying this diagram into Terraform.

## Capacity

Use [peak-capacity-worksheet.csv](https://www.factualminds.com/examples/architecture-blog-2026/ecommerce-scalability/peak-capacity-worksheet.csv) to set API Gateway RPS, DynamoDB WCU, and queue depth alarms. Pair with [event throughput tier selection](/blog/aws-high-throughput-event-processing-tier-selection-2026/) if order fan-out exceeds a single bus comfort zone.

## What broke — cache as inventory

> **What broke** — Flash sale, minute 3. Stock counters in ElastiCache decremented on "add to cart," not on reservation. Detection: warehouse short-pick spike + negative available-to-promise in the system of record **12 minutes** later. Fix: cart no longer mutates stock; **conditional inventory write** runs inside checkout before PSP capture; cache becomes a read-through hint only.

## Payments boundary

If you never touch PAN, keep **processor tokens** and stay out of PCI scope expansion. If you do, isolate a payments account — see [FinTech payments reference architecture](/blog/aws-fintech-payments-compliance-reference-architecture-2026/).

## What to Do This Week

1. Draw your five lanes; mark which store is source of truth for inventory.
2. Confirm checkout has compensation for payment auth failures.
3. Load-test checkout at **2×** last peak using the capacity worksheet.
4. Add idempotency keys on `OrderPlaced` consumers.

## What This Post Doesn't Cover

- Omnichannel identity and lakehouse analytics
- Black Friday war-room runbooks (see peak-traffic post)
- Full PCI HSM design
- Headless CMS / content delivery beyond CloudFront basics

## FAQ

### How is this different from the Black Friday peak-traffic post?
Black Friday covers surge tactics and capacity theater for a peak day. This post is the steady transaction-plane reference architecture (cart, inventory, checkout, orders) you run every day and then scale.

### How is this different from the retail omnichannel analytics lakehouse post?
That post is the analytics plane (S3 Tables/Iceberg, identity resolution). This post never designs the lake — only purchase-path systems.

### When should we NOT put cart in DynamoDB?
When cart must join deeply relational promotions already locked in Aurora and migration cost exceeds benefit. Prefer DynamoDB for high-churn carts with TTL; keep Aurora for financial orders if that is your system of record.

### What could go wrong with inventory reservation?
Using ElastiCache or CDN as the inventory source of truth. Oversells happen when reservation is not a conditional write/row lock before payment capture.

### Should checkout be synchronous Lambda only?
Only for ≤3 steps with no compensation. Otherwise Step Functions with explicit fail/compensate states — especially for payment auth vs capture.

### Do we need a PCI-scoped account?
If cardholder data touches your VPC, yes — see the FinTech payments reference architecture. Prefer processor tokens (SAQ A) when possible.

---

*Source: https://www.factualminds.com/blog/aws-ecommerce-scalability-reference-architecture-2026/*