System Design Interview
Online marketplace inspired by large retailers' published patterns: CDN-cached catalog, faceted search, durable carts, conditional inventory reservations, idempotent orders, and a payment saga driven by a transactional outbox. A teaching design.
See how a sale overwhelms one server and oversells stock.
What was missing: Nothing yet.
Why that's risky: Two shoppers can both read the last unit as available and both order it, and a sale's traffic swamps one server and database.
What gets added: One server rendering pages and placing orders by reading stock and then writing the order.
Trade-offs: Simple, but correctness depends on timing.
Take browsing off the database and make checkout unable to oversell.
What was missing: Browsing hit the database and checkout could oversell.
Why that's risky: Shoppers can't search, carts don't survive across devices, and orders and stock share one database.
What gets added: A CDN for images and cacheable pages, a catalog service with a product cache and its own database, and a checkout that decrements stock and creates the order in one transaction.
Trade-offs: Cached prices can lag a change for a moment; checkout always uses the database's current stock.
Let shoppers find products and keep carts across devices.
What was missing: No search and no durable carts.
Why that's risky: During a sale, checkout transactions on one database become the bottleneck, and a retried checkout can create two orders.
What gets added: A faceted search service and index kept current by a catalog indexer, and a cart service with a key-value cart store that survives across devices.
Trade-offs: Search lags catalog changes by seconds.
Scale stock and orders independently and make retries safe.
What was missing: Stock and orders shared one database, and retries could duplicate orders.
Why that's risky: Payment happens inside checkout, so a slow payment provider blocks the shopper and a crash mid-way leaves stock reserved with no order.
What gets added: An inventory service that reserves stock per SKU and warehouse with a conditional decrement, and an orders database where each order carries an idempotency key, so a retried checkout returns the same order.
Trade-offs: Reserved stock is unavailable to others until the order is paid or the reservation expires.
Charge, fulfill and notify reliably without a distributed transaction.
What was missing: Payment, fulfillment and notifications ran inside the checkout request.
Why that's risky: Bots can still swamp a sale, recommendations are missing, and the funnel isn't monitored.
What gets added: Checkout writes the order and an outbox event in one transaction; the event is published to an order stream, where a payment worker charges with the idempotency key (cancelling and releasing stock on failure), a fulfillment worker ships, and a notification worker emails.
Trade-offs: The order is confirmed a moment after checkout, once payment succeeds, instead of inside one request.
Help shoppers discover products, keep bots out, and watch the funnel.
What was missing: No recommendations, no bot protection, no funnel monitoring.
Why that's risky: Remaining risk is regional and seasonal: sale days need capacity planned in advance.
What gets added: A recommendations service serving precomputed related-product lists, a bot shield, and monitoring of checkout success, payment failures, oversell checks and search latency.
Trade-offs: Precomputed recommendations update nightly rather than per click.
Use inventory reservations (short TTL holds) at checkout. Decrement atomically within a transaction on order confirmation. Release holds on timeout/cancel. Consider per-SKU counters with row locks or conditional updates.
Require a client-supplied idempotency key for checkout. Persist the key with the final outcome. Use the outbox pattern to publish order events reliably. Make payment capture idempotent via unique transaction keys.
Maintain a dedicated search index (inverted) updated asynchronously from catalog changes and order signals. Support facets/filters and ranking by popularity/recency. Keep an indexing worker that consumes catalog events.
Represent promo budget/usage with atomic counters guarded by conditional updates. Cache promo definitions; validate at checkout with a read‑through cache and fallback to DB on misses.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
