Design an Inventory Management System

Two-Phase Reservation Lifecycle

The two-phase reservation flow forms the architectural backbone for consistency, ensuring that checkout reservations never result in overselling.

Normal catalog traffic relies on cached PostgreSQL sellable counts, whereas flash sale traffic shifts to Redis atomic decrements and reconciles back to the durable database ledger asynchronously after the event.

Event Bus Design (Kafka)

Stock mutations fan out asynchronously to ensure the reservation API maintains p99 latencies under 50ms, decoupling channel updates and audit streams from the critical checkout path.

Topic: stock-changes
  Partitions: 128
  Partition key: sku_id (preserves per-SKU mutation ordering)
  Retention: 7 days (channel sync replay)
  Replication factor: 3, min.insync.replicas: 2

Producer: Inventory Service after PostgreSQL commit (transactional outbox)
  Event: { event_id, sku_id, warehouse_id, delta, new_qty, reason, timestamp }

Consumer groups:
  1. channel-sync: push stock to Amazon/eBay/Shopify within seconds
  2. analytics: ClickHouse inventory movement reporting
  3. low-stock-alerts: sku below reorder point to trigger procurement notification

Topic: reservation-events (reserved, confirmed, released) consumed by Order Service saga
Topic: low-stock-alerts: notify procurement team

Sync path: GET /stock reads Redis cache-aside; reserve uses PostgreSQL + Redis DECR
Async path: channel sync and analytics never block stock check < 10ms
DLQ: stock-changes-dlq; alert when consumer lag > 30s

Flash Sale Concurrency: Redis Counter

When interviewers probe spike traffic, explain that PostgreSQL row locks collapse under concurrent transactions. We offload atomic decrements to Redis and reconcile back to the database later.

Problem: Flash sale of 1,000 units. 500K users hit "Buy" simultaneously.
  PostgreSQL: SELECT ... FOR UPDATE → row-level lock → 500K waiting → timeout/crash

Solution: Use Redis as the fast path for stock decrements.

Pre-sale setup:
  SET flash_stock:{sku_id} 1000

On purchase attempt:
  local remaining = redis.call('DECR', 'flash_stock:SKU-FLASH-1')
  if remaining >= 0 then
    -- SUCCESS: user got one
    -- Async: write to PostgreSQL, create order
    return 'reserved'
  else
    -- SOLD OUT
    redis.call('INCR', 'flash_stock:SKU-FLASH-1')  -- undo the DECR
    return 'sold_out'
  end

Why this works:
  Redis DECR is atomic (single-threaded) → no race conditions
  500K DECR operations/sec → Redis handles easily (100K ops/sec per shard)
  After Redis confirms → async write to PostgreSQL (no lock contention)

Multi-Warehouse Stock Allocation Strategies

Multi-warehouse allocation is a common interview probe. Clarify whether you optimize for shipping costs, delivery speed, or regional inventory balance. Amazon's hybrid scoring model demonstrates a strong senior design approach.

User orders SKU-123. It's available in 3 warehouses:
  WH-NYC: 50 units (200 miles from user)
  WH-CHI: 30 units (700 miles)  
  WH-LAX: 100 units (2500 miles)

Allocation strategies:

1. Nearest warehouse (minimize shipping cost + time):
   Sort warehouses by distance to delivery address
   Pick closest with stock → WH-NYC ✓

2. Load-balanced (prevent one warehouse from depleting):
   Pick warehouse with highest stock level → WH-LAX

3. Cost-optimized (minimize total fulfillment cost):
   cost = shipping_cost + handling_cost + last_mile_cost
   Consider: shipping zone, carrier rates, warehouse labor cost
   Pick minimum cost

4. Hybrid ⭐ (Amazon's approach):
   score = w1 x (1 / distance) + w2 x stock_level + w3 x (1 / cost) 
           + w4 x delivery_speed_guarantee
   Pick highest score

Split shipment:
  Order has 3 items: SKU-A (only in WH-NYC), SKU-B (only in WH-LAX), SKU-C (both)
  → Split into 2 shipments: {SKU-A, SKU-C} from WH-NYC, {SKU-B} from WH-LAX
  → Minimize number of shipments while respecting stock constraints
  → NP-hard problem at scale → greedy heuristic: maximize items per shipment