Design a Flash Sale with a Virtual Queue and Exact Inventory

Scenario

A major entertainment brand regularly releases high-demand, limited-quantity items—such as opening-day theme park passes, VIP experience packages, and exclusive merchandise drops. Millions of users arrive at the landing page within seconds of the sale going live. You need to design an end-to-end flash-sale architecture that absorbs sudden traffic spikes, meters user entry via a virtual waiting room, guarantees exact inventory tracking without overselling or lost sales, and ensures safe, idempotent checkout.

Requirements

Functional Requirements

• Virtual Waiting Room: When demand exceeds capacity, direct arriving users to a waiting queue with transparent position and estimated wait times.
• Controlled Admission: Admit queued users into the shopping experience at a rate calibrated to backend system throughput using cryptographically verifiable admission tokens.
• Exact Inventory Reservation: Allow admitted users to hold an item for a fixed reservation window (e.g., 10 minutes). Ensure strictly zero oversell.
• Hold Expiration & Rollback: Automatically release expired reservations back to the available inventory pool if checkout is not completed in time.
• Idempotent Checkout: Ensure duplicate requests (e.g., retries, network hiccups) never result in double charges or multiple orders for the same reservation.

Non-Functional Requirements

• Strict Consistency for Inventory: Zero overselling under any failure or concurrency scenario.
• High Availability for Ingress: The edge/queue layer must withstand massive spikes without crashing (99.99% availability).
• Fault Tolerance: Worker crashes or payment provider timeouts must not leak reserved inventory or leave orders in an ambiguous state.
• Fairness & Bot Mitigation: Provide reasonable defense against scripted abuse and queue-jumping.

Scale & Traffic Assumptions

• Peak Traffic: 2,000,000 concurrent users waiting at drop time.
• Inventory Size: 25,000 units per flash event.
• Admission Rate: 500 to 1,000 users per second admitted to the reservation stage.
• Reservation TTL: 10 minutes.
• Target Latency: Under 200 ms for queue status updates and reservation attempts.

Key Areas to Cover

1. High-Level Architecture: Edge layer/CDN, waiting room service, admission gatekeeper, inventory service, payment/checkout pipeline, and notification workers.
2. Virtual Queue & Admission Mechanism: Queue data structures (e.g., Redis sorted sets vs. token-bucket counters), admission token generation (signed JWTs with expiry and user ID), and secure validation at the API gateway.
3. Inventory Management: Atomicity mechanism (e.g., Redis Lua script with persistent database sync, or transactional DB locks with row-level constraints). Strategy for TTL-based hold management and inventory replenishment upon abandon/expiration.
4. Checkout & Idempotency: End-to-end checkout flow using idempotency keys, handling asynchronous payment webhooks, and ensuring database consistency via the transactional outbox pattern.