Design an e-commerce platform

Problem Statement

Design an e-commerce marketplace similar to eBay where buyers browse a large product catalog, compare offers from multiple sellers, manage shopping carts, place orders, and complete checkout with payment processing. The platform must handle the full purchase lifecycle from product discovery through order fulfillment.

The system serves millions of daily active users generating heavy read traffic on product listings and search, with periodic write bursts during promotions and flash sales. Inventory is scarce for popular items, making race conditions a real concern when multiple buyers attempt to purchase the last available unit simultaneously. Your design must ensure that no item is oversold, payments are processed exactly once, and the checkout flow degrades gracefully when downstream services experience issues. Consider how you would separate read-heavy catalog browsing from write-heavy transactional operations.

Key Requirements

Functional

• Product discovery -- users search and filter products by category, price range, ratings, and seller; browse paginated results with sorting options
• Shopping cart -- users add, update quantities, and remove items from a persistent cart that survives session changes and device switches
• Checkout and payment -- users provide shipping details, see tax and fee breakdowns, authorize payment, and receive order confirmation
• Order management -- users view order history, track shipment status, and initiate cancellations or returns when policies permit

Non-Functional

• Scalability -- support 10,000 product searches per second and 500 checkout transactions per second during peak traffic
• Reliability -- guarantee no overselling under concurrent load; ensure 99.9 percent uptime for the checkout path
• Latency -- return search results within 300 milliseconds; complete checkout confirmation within 2 seconds including payment authorization
• Consistency -- strong consistency for inventory updates during purchase; eventual consistency acceptable for search index and product catalog updates

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Inventory Consistency Under Concurrent Load

When multiple buyers race for limited stock, overselling erodes trust and creates fulfillment problems. Interviewers expect transactional mechanisms that prevent selling more units than available.

Hints to consider:

• Use database-level locking (SELECT FOR UPDATE) or optimistic concurrency control (version numbers) when decrementing inventory during checkout
• Implement a two-phase reservation: soft-hold inventory with a short TTL while the user completes payment, then convert to a confirmed sale
• Cache "sold out" signals in Redis to short-circuit availability checks without hitting the primary database
• Design automatic release of unpaid reservations after timeout to keep inventory flowing

2. Search and Catalog Read Scalability

Search traffic vastly exceeds transaction volume, and complex filtering queries would overwhelm a transactional database. Interviewers look for separation of concerns between OLTP and search infrastructure.

Hints to consider:

• Use Elasticsearch for full-text search, faceted filtering, and relevance ranking on product metadata
• Denormalize availability flags and minimum prices into the search index, refreshing asynchronously from inventory events
• Cache popular search queries and product detail pages in Redis with appropriate TTLs
• Paginate results and fetch detailed inventory only for items on the current page, not the entire result set

3. Checkout Workflow and Payment Safety

Checkout spans multiple services (tax calculation, shipping estimation, payment authorization, order creation) and must handle partial failures without double-charging or orphaned inventory holds.

Hints to consider:

• Model the checkout as a saga with explicit states: CartReady, PaymentPending, PaymentAuthorized, OrderConfirmed
• Generate idempotency keys for payment requests so retries do not create duplicate charges
• Use the outbox pattern to durably record intent before calling payment provider APIs
• Design compensating transactions: if order creation fails after payment succeeds, schedule an automatic refund

4. Cart Persistence and Session Management

Carts must survive browser closes, app switches, and device changes. Interviewers probe how you store cart state efficiently and handle stale pricing or out-of-stock items.

Hints to consider:

• Store cart state in a fast key-value store (Redis) keyed by user ID, with periodic persistence to a durable database
• Re-validate item availability and pricing at checkout initiation rather than at add-to-cart time
• Handle cart merges when an anonymous user signs in and already has items in an authenticated cart
• Set TTLs on inactive carts to free resources and periodically notify users about expiring items

Suggested Approach

Step 1: Clarify Requirements

Confirm whether you are designing a single-seller storefront or a multi-seller marketplace, as this affects catalog management and checkout flows. Ask about expected traffic (searches per second, orders per second) and product catalog size. Clarify payment methods and currency support. Verify if flash sales or promotional events with extreme traffic spikes are in scope. Establish whether real-time recommendations and personalization are required.

Step 2: High-Level Architecture

Sketch service-oriented components: Product Catalog Service (manages listings, images, and seller information in a relational database), Search Service (backed by Elasticsearch for queries and faceted filtering), Cart Service (Redis-backed with durability fallback), Inventory Service (authoritative source of available quantities with transactional guarantees in PostgreSQL), Checkout Orchestrator (coordinates the saga across inventory, payment, tax, and order services), Payment Service (wraps provider APIs with idempotency and retry logic), Order Service (manages order lifecycle and shipment tracking). Place a CDN for static assets and product images, and use Kafka to propagate inventory changes to the search index asynchronously.

Step 3: Deep Dive on Inventory and Checkout

Walk through a purchase flow. The user clicks "Buy Now" and the Checkout Orchestrator starts a database transaction against the Inventory Service. It queries available quantity with a row-level lock (SELECT available_count FROM inventory WHERE product_id = ? AND variant_id = ? FOR UPDATE), decrements the count, and inserts a reservation with a 10-minute expiration and PENDING status. The orchestrator then calls the Payment Service with an idempotency key derived from order ID. On payment authorization, the reservation transitions to CONFIRMED and a row is inserted into the Orders table. If payment fails, the transaction rolls back and inventory is released. A background job scans for expired reservations every 30 seconds and releases them. Discuss how the row-level lock prevents two concurrent transactions from overselling, and how indexing on (product_id, variant_id) keeps the lock scope narrow.

Step 4: Address Secondary Concerns

Cover read scalability: product browse and search queries hit Elasticsearch and Redis caches, never the transactional inventory database. Inventory changes publish events to Kafka that update the Elasticsearch index with eventual consistency. Discuss monitoring: track checkout success rates, reservation timeout rates, payment failure rates, and search latency percentiles. Address multi-region considerations: read replicas near users for catalog queries with all inventory writes routed to a primary region. Explain fraud detection by scoring transactions against behavioral patterns and flagging anomalies. Touch on observability needs including distributed tracing across the checkout saga to diagnose slow steps.

Related Learning Resources

• Design Ticketmaster -- covers inventory reservation under contention, payment coordination, and handling traffic spikes
• Databases -- transactional guarantees, row-level locking, and partitioning for high-throughput writes
• Caching -- Redis-backed cart storage, search result caching, and cache invalidation patterns