Q: How do you implement a virtual queue for flash sale fairness?

At sale start (T+0), instead of all users hitting the inventory directly, put them in a queue: RPUSH sale:{id}:queue {user_id} in Redis. Each enqueue returns the queue position. A pool of workers pops from the queue (LPOP) and processes purchases in FIFO order. Users with queue positions 1-1000 (for 1000 units) get purchase slots. Users beyond position 1000 receive sold out notification immediately. Display real-time queue position updates via WebSocket. The queue absorbs the burst: Redis handles 1M RPUSH/second, the workers process at their sustainable rate. This is fairer than a pure race where network proximity to the server determines who wins.

Q: How do you handle checkout timeouts in a flash sale?

When a user reserves inventory (DECRBY succeeds), create a RESERVED order with expires_at = NOW() + 10 minutes. The user has 10 minutes to complete payment. A background job runs every minute: SELECT * FROM sale_orders WHERE status = RESERVED AND expires_at < NOW(). For each expired order: cancel it (status=CANCELLED), INCRBY sale:{id}:stock 1 (restore Redis counter), offer the slot to the next user in the queue (if any). This recirculates abandoned slots back to waiting buyers. The 10-minute window must be short enough to not block other buyers long, but long enough for a normal checkout flow (payment form, credit card entry).

Q: How do you enforce one purchase per user in a flash sale?

Insert a record into a user_sale_eligibility table with a unique constraint on (user_id, sale_id): INSERT INTO user_sale_eligibility (user_id, sale_id, purchased_at) ON CONFLICT (user_id, sale_id) DO NOTHING RETURNING *. If no rows are returned, the user already has a record -- reject the purchase attempt. Do this check BEFORE the Redis DECRBY to avoid decrementing stock for ineligible users. For multiple quantity limits (max 2 per user): store quantity_purchased in the row and use SELECT FOR UPDATE to atomically check and increment. At very high scale, pre-load known-ineligible users into a Redis SET (SISMEMBER) for O(1) pre-check before hitting the database.

Q: How do you pre-warm infrastructure before a flash sale starts?

T-60 minutes: pre-populate Redis with stock counter (SET sale:{id}:stock 1000), product metadata cache, and user eligibility blacklists (accounts flagged for abuse or fake accounts). Configure auto-scaling policies to pre-scale application servers to 5x normal capacity -- do not rely on auto-scaling reacting to the burst (it is too slow). T-30 minutes: run a load test to verify the scaled infrastructure can handle expected peak. T-5 minutes: enable the waitlist page (captures user intent, avoids pre-sale DB hits). Send push notifications and emails to remind registered users. T-0: flip the sale status to ACTIVE in Redis. Monitor error rate, queue depth, and Redis memory every 30 seconds during the sale. Have rollback procedures ready if any component degrades.

Question 1

How do you prevent overselling in a flash sale with high concurrency?

Accepted Answer

Use Redis atomic DECRBY as the first gate. At sale start: SET sale:{id}:stock 1000. On each purchase: result = DECRBY sale:{id}:stock 1. If result >= 0, reservation is allowed. If result < 0: INCRBY to restore (compensate) and reject with sold out. Redis DECRBY is single-threaded and atomic -- no two requests can decrement the same counter simultaneously. This handles 100K+ concurrent requests without race conditions. Second gate at the database: UPDATE flash_sales SET quantity_sold = quantity_sold + 1 WHERE sale_id = X AND quantity_sold < quantity_available returns 0 rows if stock is exhausted at the DB level -- final safety net if Redis and DB get out of sync.

Question 2

How do you implement a virtual queue for flash sale fairness?

Accepted Answer

At sale start (T+0), instead of all users hitting the inventory directly, put them in a queue: RPUSH sale:{id}:queue {user_id} in Redis. Each enqueue returns the queue position. A pool of workers pops from the queue (LPOP) and processes purchases in FIFO order. Users with queue positions 1-1000 (for 1000 units) get purchase slots. Users beyond position 1000 receive sold out notification immediately. Display real-time queue position updates via WebSocket. The queue absorbs the burst: Redis handles 1M RPUSH/second, the workers process at their sustainable rate. This is fairer than a pure race where network proximity to the server determines who wins.

Question 3

How do you handle checkout timeouts in a flash sale?

Accepted Answer

When a user reserves inventory (DECRBY succeeds), create a RESERVED order with expires_at = NOW() + 10 minutes. The user has 10 minutes to complete payment. A background job runs every minute: SELECT * FROM sale_orders WHERE status = RESERVED AND expires_at < NOW(). For each expired order: cancel it (status=CANCELLED), INCRBY sale:{id}:stock 1 (restore Redis counter), offer the slot to the next user in the queue (if any). This recirculates abandoned slots back to waiting buyers. The 10-minute window must be short enough to not block other buyers long, but long enough for a normal checkout flow (payment form, credit card entry).

Question 4

How do you enforce one purchase per user in a flash sale?

Accepted Answer

Insert a record into a user_sale_eligibility table with a unique constraint on (user_id, sale_id): INSERT INTO user_sale_eligibility (user_id, sale_id, purchased_at) ON CONFLICT (user_id, sale_id) DO NOTHING RETURNING *. If no rows are returned, the user already has a record -- reject the purchase attempt. Do this check BEFORE the Redis DECRBY to avoid decrementing stock for ineligible users. For multiple quantity limits (max 2 per user): store quantity_purchased in the row and use SELECT FOR UPDATE to atomically check and increment. At very high scale, pre-load known-ineligible users into a Redis SET (SISMEMBER) for O(1) pre-check before hitting the database.

Question 5

How do you pre-warm infrastructure before a flash sale starts?

Accepted Answer

T-60 minutes: pre-populate Redis with stock counter (SET sale:{id}:stock 1000), product metadata cache, and user eligibility blacklists (accounts flagged for abuse or fake accounts). Configure auto-scaling policies to pre-scale application servers to 5x normal capacity -- do not rely on auto-scaling reacting to the burst (it is too slow). T-30 minutes: run a load test to verify the scaled infrastructure can handle expected peak. T-5 minutes: enable the waitlist page (captures user intent, avoids pre-sale DB hits). Send push notifications and emails to remind registered users. T-0: flip the sale status to ACTIVE in Redis. Monitor error rate, queue depth, and Redis memory every 30 seconds during the sale. Have rollback procedures ready if any component degrades.

Low-Level Design: Flash Sale System — Inventory Lock, Queue-based Checkout, and Oversell Prevention

The Core Challenge

Core Entities

Inventory Reservation with Redis

Queue-based Checkout for Fairness

Preventing Oversell

Per-User Purchase Limits

Pre-sale Warm-up

Post-sale Processing