System Design Interview
Global multi-vendor marketplace with product catalog, search, cart/checkout, payments, inventory, order management, media, recommendations, and analytics.
Single service for catalog/cart/checkout with one database.
What was missing: Edge/CDN, caching, async processing, and isolation.
Why that's risky: SPOF and poor surge handling.
What gets added: Nothing yet (MVP).
Trade-offs: Fast to ship, not production-ready.
Add ingress protection and static/media offload before business logic.
What was missing: Global media delivery and ingress protection.
Why that's risky: Origin overload and high tail latency.
What gets added: CDN and rate limiting at the edge.
Trade-offs: Cache invalidation and signed URL management.
Scale API behind LB and add cache for catalog/session reads.
What was missing: Redundancy and hot-path caching.
Why that's risky: Bottlenecks and slow reads.
What gets added: LB replicas and cache.
Trade-offs: Cache invalidation and session management.
Separate catalog/cart/checkout; add dedicated DBs and keep cache in front of read-heavy paths.
What was missing: Tight coupling across domains and hot DB reads.
Why that's risky: Slow UX and wide deploy blast radius.
What gets added: Service separation and dedicated stores plus cache.
Trade-offs: Cache invalidation and cross-service contracts.
Add PCI-isolated payments, inventory holds/decrement, and outbox-driven events with workers.
What was missing: PCI isolation, inventory correctness, and reliable event publication.
Why that's risky: Duplicate charges/orders on retries; lost events on crashes.
What gets added: Payments + inventory services, outbox, and workers via queue.
Trade-offs: Operational complexity of outbox and background fleet.
Add search index and recommendations while preserving transactional paths; include monitoring and read replica for orders.
What was missing: Fast search, discovery, and visibility.
Why that's risky: Slow browse and weak incident insight.
What gets added: Search index + indexer, recommendations, monitoring, and orders read replica.
Trade-offs: Eventual consistency for index/reco; replica lag on reads.
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:
