· software-engineers Editorial · Career · 6 min read
Swe System Design E Commerce Platform
A production-grade system design walkthrough for an e-commerce platform: inventory, checkout, order pipeline, and the failure modes interviewers probe for.
Scoping the Problem Correctly
“Design an e-commerce platform” is one of the most commonly assigned system design prompts in 2026 SWE loops, precisely because it forces candidates to reason about multiple hard sub-problems at once: inventory consistency, payment idempotency, catalog search, and order fulfillment. Interviewers are not looking for a diagram of microservices with arrows — they’re testing whether you know which parts of this system need strong consistency and which can tolerate eventual consistency.
The correct first move is scoping: clarify scale (is this Amazon-scale at 100M+ SKUs, or a mid-size retailer at 50K SKUs?), read/write ratio (catalog reads outnumber checkout writes by 100:1 or more in nearly every real system), and which flows are money-critical (checkout, payment, inventory decrement) versus which are tolerant of staleness (product recommendations, review counts, “12 people viewing this item”).
Core Services and Data Ownership
A defensible e-commerce architecture splits into five services, each owning its own data store — this is the service-per-bounded-context pattern, not a monolith with shared tables.
- Catalog service — product metadata, pricing, images. Read-heavy, cacheable aggressively (CDN + Redis), eventually consistent is fine. Backed by a document store or read-replica’d relational DB.
- Inventory service — stock counts per SKU per warehouse. This is the hardest consistency problem in the whole system: two customers can’t both “win” the last unit. Requires either row-level locking with
SELECT FOR UPDATE, an atomic decrement (UPDATE inventory SET count = count - 1 WHERE count > 0), or a reservation-with-TTL pattern. - Cart service — per-user cart state. Can be eventually consistent and stored in Redis or DynamoDB with TTL, since a lost cart is annoying, not catastrophic.
- Order service — the system of record for what was purchased. Must be ACID-compliant, append-only, and the source of truth for order status transitions (placed → paid → fulfilled → shipped).
- Payment service — usually a thin wrapper around Stripe/Adyen, but the wrapper itself must guarantee idempotency (see below) since payment providers retry webhooks.
The Checkout Flow: Where Correctness Bugs Live
Checkout is the flow interviewers drill into hardest because it combines a distributed transaction (decrement inventory + charge card + create order) with a hard business requirement: never double-charge, never oversell.
The production pattern that works at scale is the saga pattern with compensating transactions, not a two-phase commit (2PC is almost never used in real e-commerce systems because it blocks and doesn’t survive partition well across service boundaries). The sequence:
- Reserve inventory (decrement with a TTL-based hold, not a hard decrement) — if this fails, checkout fails immediately, cheaply, before touching payment.
- Charge the payment provider using an idempotency key derived from the order attempt ID — this is non-negotiable; without it, network retries cause double charges.
- On payment success, convert the inventory hold into a hard decrement and create the order record.
- On payment failure, release the inventory hold (compensating action) so the unit returns to the sellable pool.
- If the process crashes between steps 2 and 3, a reconciliation job (polling payment provider status against pending orders) recovers the state — this is why every payment integration needs a background reconciler, not just a happy-path webhook handler.
Comparison: Consistency Strategy by Subsystem
| Subsystem | Consistency model | Why | Failure cost if wrong |
|---|---|---|---|
| Inventory count | Strong (row lock or atomic decrement) | Overselling is a direct financial and trust cost | Refunds, angry customers, chargebacks |
| Payment charge | Strong + idempotent | Double-charging is a legal/compliance issue | Chargebacks, regulatory exposure |
| Order status | Strong (single system of record) | Customers and support need one truth | Support tickets, disputes |
| Product catalog | Eventual (cache-friendly) | Staleness of a price update by seconds is tolerable | Minor, self-correcting |
| Recommendations/reviews | Eventual, can be minutes stale | Zero correctness requirement | None |
| Cart contents | Eventual, best-effort | Losing a cart is recoverable | Minor UX friction |
Search, Scale, and the Read Path
Catalog search at any real scale (10K+ SKUs) is not a LIKE '%query%' query against the primary database — that’s a common junior mistake interviewers watch for. Production catalog search runs on a dedicated search index (Elasticsearch/OpenSearch or a managed equivalent), fed by a change-data-capture (CDC) pipeline off the catalog database (Debezium reading the binlog/WAL, publishing to Kafka, consumed by an indexer). This decouples search freshness from the transactional database and lets search scale independently — a critical point to raise explicitly, since it demonstrates you understand CDC as a pattern, not just as a buzzword.
On the read path more broadly: product pages should be served from CDN edge cache for anonymous traffic (95%+ of catalog browsing), with personalization (recently viewed, recommendations) hydrated client-side via a separate low-latency call, rather than busting the cache per-user. This single decision — separating cacheable page shell from personalized fragments — is one of the highest-leverage architecture calls in e-commerce and a strong signal in an interview when you raise it unprompted.
What Interviewers Are Actually Scoring
Across dozens of e-commerce system design loops conducted in 2026, the differentiator between a pass and a strong-hire is rarely the box-and-arrow diagram — it’s whether the candidate can name the specific failure mode at each service boundary (double charge, oversell, lost order) and state the specific mechanism that prevents it (idempotency key, atomic decrement with hold, CDC-fed search index). Candidates who describe services without naming failure modes get “design a distributed system” feedback, not “strong hire.”
This exact checkout-and-inventory reasoning, including the saga pattern walkthrough and common interviewer follow-up questions, is broken down step by step in The 0-to-1 SWE Interview Playbook — available on Amazon.
FAQ
Q: Should I use 2PC (two-phase commit) for the checkout transaction? No, and saying you would is a red flag in most 2026 interviews. 2PC blocks on coordinator failure and doesn’t scale across independently-deployed services. Use the saga pattern with compensating transactions instead.
Q: How do you prevent overselling the last unit of a popular item under high concurrency?
Use an atomic conditional decrement (UPDATE inventory SET count = count - 1 WHERE sku = ? AND count > 0, checking rows affected) or a distributed lock with a short TTL reservation, never a read-then-write in application code, which has a race condition window.
Q: Where should product search live relative to the transactional database? In a dedicated search index fed by CDC, never queried directly against the same database serving checkout writes — mixing the two couples search load to transactional latency and vice versa.