E-commerce Scalability on AWS (2026): Cart, Checkout, Inventory, and Order Event Reference Architecture
Quick summary: 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.
Key Takeaways
- 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
- 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
Table of Contents
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
| 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 / loyaltyWalk 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
- Draw your five lanes; mark which store is source of truth for inventory.
- Confirm checkout has compensation for payment auth failures.
- Load-test checkout at 2× last peak using the capacity worksheet.
- Add idempotency keys on
OrderPlacedconsumers.
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
AWS Cloud Architect & AI Expert
AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.
