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

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 but need a lane map.

It is not Black Friday peak tactics, not omnichannel analytics lakehouse, and not SES ecommerce email.

Artifacts: lane decision matrix, peak capacity worksheet, architecture diagram (draw.io).

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

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 before copying this diagram into Terraform.

Capacity

Use peak-capacity-worksheet.csv to set API Gateway RPS, DynamoDB WCU, and queue depth alarms. Pair with event throughput tier selection 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.

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
• AI agents over this transaction plane — see the eCommerce AI Agents series, in particular the AI-ready data layer and agent-ready storefront

Frequently asked questions