Design a Scalable E-commerce Backend — System Design Interview Practice

Interview prompt

Design a cost-efficient e-commerce backend that handles catalog browsing, inventory, checkout, payments, fulfillment, and traffic spikes while preserving order correctness.

• Define catalog, inventory reservation, cart, order, payment, shipment, and return boundaries with idempotent state transitions.
• Keep browse reads highly cacheable while making checkout strongly correct around stock, totals, payment authorization, and order creation.
• Design for flash-sale bursts, hot products, asynchronous fulfillment, payment webhooks, retries, reconciliation, and dead-letter recovery.
• Explain security, fraud controls, observability, cost guardrails, and degraded browsing or checkout behavior.

Requirements and scale assumptions

• Browse and search products, manage carts, reserve inventory, create orders, authorize/capture/refund payments, and track fulfillment.
• Support authenticated customers, guest checkout, promotions, tax/shipping quotes, seller/admin updates, and order history.
• Make retries safe, reconcile payment and inventory mismatches, audit sensitive actions, and recover from partial workflow failures.
• Meet p95 browse latency under 200ms and checkout confirmation under 2 seconds excluding external payment latency.
• Scale from quiet periods to 100x flash-sale bursts without a single hot key or unbounded synchronous work.
• Do not lose committed state; make retries and duplicate events safe.
• Degrade safely when downstream workers, caches, or external dependencies fail.
• 100x traffic bursts; 50k checkout attempts per minute
• Partition by the primary tenant, user, item, or geographic key and isolate hot partitions.
• Keep serving state bounded; retain raw events or durable records for replay and auditing.

• Peak scale: 50k checkout attempts/minute — Capacity assumption that drives partitioning and backpressure.
• Latency target: browse p95 < 200ms; checkout < 2s — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — Order, inventory, and payment ledgers are authoritative; search and caches are rebuildable projections.
• Async boundary: At-least-once workers — Keep Use API Gateway for REST endpoints, Lambda for business logic, DynamoDB for product catalog and orders off the synchronous path.

Key entities

• OrderIntentintentId, customerId, offerId, status, version, idempotencyKey

  Idempotent scalable e commerce backend order intent with an explicit lifecycle.

• InventoryClaimclaimId, itemId, quantity, expiresAt, status, version

  Short-lived conditional claim that protects scarce inventory.

• PaymentAttemptattemptId, intentId, provider, requestHash, status, providerRef

  Retry-safe payment attempt with unknown-outcome reconciliation.

• FulfillmentStateintentId, stage, owner, lastEventId, status, updatedAt

  Durable downstream order fulfillment progress.

Data flow

1. 1. Search and price current candidatesThe scalable e commerce backend query path combines catalog, eligibility, price, and current availability without treating a stale index as a final claim.
2. 2. Claim scarce inventoryThe scalable e commerce backend service creates a short-lived conditional claim keyed by item and request idempotency before charging or confirming.
3. 3. Confirm the order safelyPayment, policy, and inventory transitions are versioned; unknown provider outcomes are reconciled before retry.
4. 4. Publish fulfillment workThe committed scalable e commerce backend intent emits an event for partner, packing, delivery, or campaign dispatch workers.
5. 5. Expire, cancel, and reconcileExpiry and cancellation release claims idempotently while reconciliation compares internal state with external providers or partners.

Deep dives and trade-offs

• Inventory claims and oversell controlUse conditional writes or a serialized inventory partition for scalable e commerce backend scarce capacity. Give holds an expiry and reaper, but never release a confirmed claim from a stale worker. Separate searchable availability from the authoritative claim path.
• Payment and unknown outcomesBind scalable e commerce backend payment attempts to the intent and request hash, not just the customer session. Treat timeout as unknown, query or reconcile provider state, and avoid a blind second charge. Keep sensitive payment tokens outside business records and logs.
• Fulfillment and partner recoveryPublish scalable e commerce backend events after commit, consume at least once, and track per-stage progress. Use reconciliation against partner feeds or delivery evidence instead of assuming a callback arrives. Expose pending and expired status so the client can explain what happened.
• Reservation versus oversell tolerancePrefer a short-lived scalable e commerce backend claim for scarce inventory and state the consistency scope explicitly. A cache or search index cannot safely decrement the final stock count.
• Synchronous checkout versus asynchronous fulfillmentCommit the order intent synchronously and move partner or delivery work behind events. Waiting for downstream fulfillment makes retries ambiguous and increases checkout tail latency.
• Precompute availability versus compute at read timePrecompute common search dimensions but validate the final claim against authoritative state. Serving only a precomputed scalable e commerce backend availability view creates oversell or stale-price failures.