Design a Shopping Cart System

In-Memory Key-Value Storage

Cart reads occur on almost every storefront page navigation, so authenticated cart data is maintained in Redis Hashes with sub-millisecond access. For a broader overview of caching tiers, review Redis Patterns and Caching Patterns. Anonymous guest carts remain on the client device until login triggers an atomic Lua script merge into the primary user key.

Event Bus Design (Kafka)

Cart state changes stream asynchronously to Kafka for analytics and relational snapshots, completely decoupled from the latency-sensitive add-to-cart path.

Topic: cart-events
  Partitions: 64
  Partition key: user_id (preserves per-user cart event ordering)
  Retention: 7 days
  Replication factor: 3, min.insync.replicas: 2

Producer: Cart Service on mutation (idempotent producer)
  Event: { event_id, user_id, action: "add" | "remove" | "update" | "checkout" | "abandon", items[], total_value, timestamp }

Consumer groups:
  1. abandonment-recovery: triggers recovery emails if no checkout occurs within 1 hour (suppressed if purchased or cart < $10)
  2. analytics: ingests cart funnels into ClickHouse to evaluate drop-offs
  3. recommendation: mines "frequently added together" co-occurrence patterns
  4. pg-backup: asynchronous snapshots from Redis cart to PostgreSQL every 5 minutes

Sync path: cart CRUD in Redis executes in under 5 ms; cart service publishes event asynchronously.
Async path: abandonment emails and analytics processing never block the add-to-cart request.
DLQ: cart-events-dlq, alerting when abandonment consumer lag exceeds 300 seconds.

Atomic Merge Workflow

Merging guest carts into existing user carts is a critical edge case. Interviewers expect an atomic transaction model rather than vulnerable read-modify-write patterns that risk race conditions.

When a guest with 3 items signs in to an account that already contains 2 items, the service merges entries by taking the maximum quantity for overlapping SKUs. Executing this logic via a Redis Lua script ensures complete atomicity against concurrent login sessions.

Scenario:
  1. Guest adds 3 items to cart (stored by session_id):
     cart:guest-session-abc -> { SKU-1: qty 1, SKU-2: qty 2, SKU-3: qty 1 }

  2. Guest logs in as user-123 with existing cart:
     cart:user-123 -> { SKU-2: qty 1, SKU-4: qty 3 }

  3. Merge strategy:
     For items present in BOTH carts (SKU-2):
       Option A: Keep higher quantity -> qty = max(2, 1) = 2
       Option B: Sum quantities -> qty = 2 + 1 = 3
       Option C: Retain guest cart quantity as most recent intent -> qty = 2
       
       Standard e-commerce convention selects Option A (max quantity) for optimal user experience.

     For items only in guest cart: insert into user cart
     For items only in user cart: retain unchanged

     Result: cart:user-123 -> { SKU-1: qty 1, SKU-2: qty 2, SKU-3: qty 1, SKU-4: qty 3 }

  4. Delete guest cart: DEL cart:guest-session-abc

Checkout Price Verification

Shopping carts frequently sit untouched for days or weeks, making product price changes and inventory depletion inevitable. Clarify your stale-pricing policy before detailing batch lookup flows.

The system adopts a hybrid resolution policy: capture item price at initial add time, then reconcile against current catalog rates during checkout. If the current price is lower, the customer receives the discount. If higher, the UI flags the increase and prompts confirmation before charging.

Implementation:
  On cart page load:
    cart_items = redis.hgetall("cart:user-123")
    current_prices = catalog_service.batch_get_prices([sku_ids])
    
    for item in cart_items:
      item.current_price = current_prices[item.sku_id]
      item.price_changed = (item.current_price != item.price_at_add)
      item.in_stock = inventory_service.check_stock(item.sku_id)
    
    return cart with annotations