System 12.17 — E-commerce
In one line
Catalog, cart, checkout, inventory, orders, payments, delivery — the multi-domain orchestration problem.
Think of it like this
Amazon's engine: browsing a catalog of millions of products, keeping accurate stock counts as thousands of people check out at once, and making sure inventory never goes negative.
Key ideas
- 01
Services: catalog, cart, checkout, inventory, order, payment, fulfillment, notification — bounded contexts (11.2).
- 02
Checkout saga: reserve inventory → charge payment → create order → schedule fulfillment; compensations on each failure.
- 03
Inventory: sku-level counts; reserve-then-release with TTL (same holds as seats); overselling prevention = atomic reserve.
- 04
Catalog: denormalized reads (title/price/image) in cache; index in ES for search/filter; price policy (decorators).
- 05
Cart: user-scoped, TTL'd, merge-on-login (guest cart → user cart) — a simple service, surprisingly full of rules.
- 06
Scale: promo-day spikes 50x — the queue + CDN + read replicas absorb; inventory writes stay strong-consistent.
- 07
Order status state machine (like food delivery): PENDING → PAID → PROCESSING → SHIPPED → DELIVERED (+ cancellations).
- 08
The interview trick: separate read-heavy (catalog, search) from write-critical (orders, inventory) and scale each differently.
Code & diagrams
The service boundaries an e-commerce HLD is graded on — especially where inventory locks live.
Explain without notes
Walk a checkout where payment succeeds but inventory reservation fails — which compensations fire and in what order?
Practice
Design the inventory reserve/release TTL and the promotion-day scaling story.
Trade-offs
- ↔
Oversell risk (weak) vs abandoned orders (strong holds) — the 5–15min hold is the market answer.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can present e-commerce: catalog read path, cart, checkout saga, inventory holds, order state machine.