Design a Flash Sale System

The Critical Purchase Path: Redis Lua Script

This is the core implementation detail interviewers probe most aggressively. The entire reservation decision must execute atomically in Redis in under 1 ms, eliminating the race conditions inherent in separate read, decrement, and write commands. The script also makes retries idempotent and checks the per user and per device limits in the same atomic path. For broader patterns, explore Redis Patterns.

-- Keys:
-- 1: flash_stock:{sale_id}:{sku_id}
-- 2: user_limit:{sale_id}:{user_id}
-- 3: idempotency:{sale_id}:{idempotency_key}
-- 4: reservation:{reservation_token}
-- 5: device:{sale_id}:{fingerprint}
-- Args: user_id, sku_id, quantity, reservation_token, idempotency_key, device_fingerprint

-- Step 0: Return the original result for a retried request
local previous = redis.call('GET', KEYS[3])
if previous then
  return {2, previous}
end

-- Step 1: Check per-user purchase limit
local user_purchased = redis.call('GET', KEYS[2])
local quantity = tonumber(ARGV[3])
if user_purchased and tonumber(user_purchased) + quantity > 2 then
  return {0, 'LIMIT_EXCEEDED'}
end

-- Step 2: Check per-device purchase ownership
local device_user = redis.call('GET', KEYS[5])
if device_user and device_user ~= ARGV[1] then
  return {0, 'DEVICE_LIMIT_EXCEEDED'}
end

-- Step 3: Atomic stock decrement
local remaining = redis.call('DECRBY', KEYS[1], quantity)
if remaining < 0 then
  redis.call('INCRBY', KEYS[1], quantity)  -- undo
  return {0, 'SOLD_OUT'}
end

-- Step 4: Record purchase limits and reservation
redis.call('INCRBY', KEYS[2], quantity)
redis.call('EXPIRE', KEYS[2], 86400)
redis.call('SET', KEYS[5], ARGV[1], 'EX', 86400)
redis.call('SET', KEYS[4], cjson.encode({
  user_id = ARGV[1],
  sku_id = ARGV[2],
  qty = quantity
}), 'EX', 600)

local result = cjson.encode({
  reservation_token = ARGV[4],
  remaining_stock = remaining
})
redis.call('SET', KEYS[3], result, 'EX', 86400)

return {1, result}

Why execute a Lua script rather than individual commands? Redis runs Lua scripts atomically without interleaving other commands. Separate read, decrement, and check calls expose a window where concurrent requests can oversell. A single Redis node can comfortably serialize 100K+ Lua executions per second, and sharding via Sharding and Partitioning scales this further across independent sales.

Virtual Queue: Handling 1M Concurrent Users

Even if Redis sustains high decrement throughput, the upstream API gateway and load balancer tier can collapse under a 500K request per second burst. A virtual waiting room regulates inbound pressure by admitting customers at a stable, controlled drain rate that can be tuned to inventory and downstream capacity.

T-5 min: Users "Enter Queue" early
  Position assigned: INCR queue_position:{sale_id} --> position 347,231
  User shown: "Your position: 347,231. Estimated wait: ~5 minutes"

T=0: Sale starts. Queue processes users FIFO.
  Gate rate: 10,000 users admitted per second (tunable)
  
  Admitted users:
  1. Receive short-lived JWT token (valid 60 seconds)
  2. Token authorizes call to purchase API
  3. Purchase API validates token --> runs Lua script on Redis
  
  Users not yet admitted:
  - See "Please wait..." with live position via WebSocket/SSE
  - Position updates every 5 seconds
  
  Stock gone:
  - Broadcast SOLD_OUT to ALL remaining queue members immediately
  - Don't make users wait if nothing left to buy

Queue implementation:
  Redis sorted set: ZADD queue:{sale_id} {timestamp} {user_id}
  Processing: ZPOPMIN queue:{sale_id} 10000  (pop 10K per second)

Anti-Bot Measures

Scalpers and automated purchase bots represent a primary operational hazard. Defend against unauthorized syndicates by deploying layered inspection filters from the network edge to the checkout service.

Layer 1: CDN/WAF (Cloudflare, AWS WAF)
  - Rate limit per IP: max 10 req/sec
  - Known bot signatures blocked
  - JavaScript challenge (bots can't execute JS)
  - TLS fingerprinting (JA3 hash) flag non-browser clients

Layer 2: Queue Entry Validation
  - CAPTCHA at queue entry (invisible reCAPTCHA)
  - Device fingerprint (canvas hash, WebGL, screen resolution)
  - Account age check: accounts < 24 hours old are blocked

Layer 3: Purchase Validation
  - One purchase per user_id (Redis user_limit)
  - One purchase per device_fingerprint
  - One purchase per payment method

Layer 4: Post-Purchase Fraud Detection
  - Multiple orders to same shipping address from different accounts are cancelled
  - Reseller pattern detection flags suspicious activity