# E-commerce System Design: What Interviewers Expect You to Nail E-commerce system diagram # E-commerce System Design: What Interviewers Expect You to Nail In backend system design interviews for e-commerce roles, interviewers expect you to cover both the core building blocks and how your design holds up under real-world constraints. Cover the essentials clearly, then defend trade-offs for traffic spikes, concurrency, low latency, and global users. Below is a concise, interview-friendly checklist with explanations and tradeoffs you should be ready to discuss. --- ## Core building blocks (explain each clearly) - **User authentication & authorization** - Options: JWT, OAuth2, session tokens. Explain where to store tokens (cookies vs local storage), refresh tokens, token revocation, and secure practices (HTTPS, same-site cookies). - Talk about role-based access, rate limiting per user, and session invalidation. - **Product catalog & search indexing** - Primary datastore for product data (relational DB or document store), and a search index (Elasticsearch/OpenSearch) for full-text, filters, and faceted search. - Discuss index update strategy: sync vs async, near-real-time indexing, and stale-index tradeoffs. - **Cart persistence** - Short-lived carts: store in Redis for speed; persistent carts: back to a DB keyed by user. - Explain session vs user-linked carts, expiration, and how to merge guest carts after login. - **Checkout & order lifecycle** - Order states: CREATED → RESERVED → PAID → FULFILLED → CANCELLED. Show how events or state machines manage transitions. - Idempotency keys for order creation and payment callbacks to avoid duplicate orders. - **Payment gateway integration** - Use external processors (Stripe, Adyen). Discuss synchronous vs asynchronous flows, webhooks, secure storage of payment references, and handling failed payments/retries. - **Inventory control (preventing oversell)** - Strategies: pessimistic locking (DB locks), optimistic locking (versioning), or reservation/hold model (reserve stock on cart/checkout for a short TTL). - Outline latency and throughput tradeoffs: locks are safe but hurt throughput; reservation introduces complexity but scales better. --- ## Defend your design under real scenarios - **Traffic spikes / sudden load (Black Friday)** - Autoscale application tiers; put a load balancer in front. Use a CDN for static content. - Cache aggressively with Redis or an LRU cache; use cache-aside pattern and tune TTLs. Consider rate limiting and graceful degradation (read-only mode, feature toggles). - Partition/shard large datasets (user or product shards) and use database replicas for read traffic. - **Real-time stock accuracy** - Event-driven architecture: publish events (order.created, order.cancelled) to a durable queue (Kafka) and have inventory services consume and update stock. - For hot items, use a reservation queue or distributed counters in Redis with atomic decrement and fallback to strong-consistent DB checks. - Be explicit about eventual consistency vs strong consistency and where each is acceptable (e.g., cart listing can be eventually consistent; final checkout needs stronger guarantees). - **Recommendations & personalization** - Offline batch models (recommendation pipelines, feature store) + online serving (low-latency caches in Redis or specialized stores like Cassandra/Scylla). - Use embeddings or collaborative filtering; keep model inference fast—precompute top-k lists for products and personalize further at request time. - **Multi-region latency & availability** - Use a global CDN for assets and edge caches for read-heavy APIs. - Replicate read data regionally and funnel writes to a primary region or use multi-master with conflict resolution. Discuss tradeoffs: cross-region consistency vs write latency. - Consider regulatory constraints and data locality. --- ## Explain tradeoffs clearly (what to say in interviews) - Consistency vs availability: identify which operations need strong consistency (inventory during checkout) and which can be eventual (product recommendations). - Latency vs correctness: caching reduces latency but risks staleness—describe invalidation or TTL strategies. - Complexity vs cost: microservices improve independence and scaling, but add operational cost (deployments, monitoring, distributed tracing). - Simplicity vs extensibility: prefer a simple, correct approach for core flows and mention how it can evolve (e.g., add reservation service later). --- ## Practical interview checklist (quick talking points) - Start with a high-level diagram and dataflow. - Define critical APIs and data models (Product, Cart, Order, Inventory). - Explain data stores and why: RDBMS vs NoSQL vs search index vs cache. - Describe concurrency control for inventory and idempotency for payments. - Discuss scalability: autoscaling, caching, sharding, and queues. - Cover observability: metrics, logs, tracing, alerting, and SLOs. - Mention security: encryption in transit/at rest, PCI compliance for payments, input validation. --- ## Closing / How to present this in interviews Start from the user journey (browse → add to cart → checkout) and expand into components. Prioritize correctness for checkout and inventory, then discuss scaling and resilience. When asked "why?", always state tradeoffs and a fallback plan. Use this checklist to structure answers: clear architecture, concise rationale, and practical tradeoffs. That approach shows you understand both design and operational realities.