Design a Flash Sale System

Functional

A flash sale system sells a limited quantity of heavily discounted products during a short time window, often just minutes. Think Amazon Lightning Deals or Xiaomi phone launches. The defining challenge: millions of users competing for thousands of items simultaneously.

Sale management:

Traffic

• 10M concurrent users at sale start. All loading the deal page simultaneously
• 100K checkout attempts/sec at peak for a popular item (e.g., a discounted phone with 1,000 units)
• Most traffic concentrated in the first 60 seconds. After 2-3 minutes, popular items sell out and traffic drops 90%.
• Each checkout involves: inventory check, payment, order creation, notification = 4 downstream calls per checkout = 400K internal requests/sec

Storage

Public APIs

GET /api/deals: List active and upcoming flash sales. Response includes deal_id, product info, original_price, sale_price, start_time, end_time, and remaining_stock. This endpoint is heavily cached, CDN serves it with a 5-second TTL during active sales so the stock count updates frequently enough without hitting origin servers on every request.

GET /api/deals/:deal_id: Single deal detail with full product description, images, and current stock. Also CDN-cached with short TTL.

Three Data Stores for Three Workloads

PostgreSQL (transactional data): Orders, users, deals, and payment records. These require ACID guarantees. A payment must atomically create an order.

Deals table: deal_id (PK), product_id (FK), title, original_price, sale_price, total_stock (the initial inventory count), start_time, end_time, status (enum: scheduled, active, ended, cancelled), max_per_user (purchase limit), created_at. Indexed on status and start_time for the "upcoming deals" query.

Architecture Overview

CDN (CloudFront/Akamai): The first line of defense. Deal listing pages, product images, and the countdown timer widget are cached at edge locations. During the sale, 99% of page-load traffic is served from CDN, never reaching origin servers. Pre-warmed before sale start.

Flash Sale Purchase Flow

Let's trace what happens when a user tries to buy a discounted phone:

Overselling Prevention Engine

This is the single most important component to get right. Overselling means the 501st user buys an item with only 500 units. In a flash sale with real money and limited inventory, this is catastrophic: you either cancel orders (angry customers) or eat the loss (ship items you don't have).

Optimistic vs. Pessimistic Locking for Inventory

The core trade-off in flash sale inventory management:

Optimistic locking (version-based): Read the current stock and version number. Attempt update: UPDATE stock SET quantity = quantity - 1, version = version + 1 WHERE deal_id = X AND version = Y. If another transaction already incremented the version, the update affects 0 rows, retry. Pros: no lock held during the transaction, so readers aren't blocked. Cons: under high contention (100K concurrent checkouts), most updates fail the version check. Retry rate approaches 99.9%, creating a storm of wasted reads.

Payment Gateway Failure During Checkout

The Payment Gateway (Stripe, Adyen) is an external dependency we cannot control.

ML-Powered Demand Prediction

Historical data from past flash sales, traffic patterns, conversion rates by product category, time of day, discount depth, can train a model that predicts demand for upcoming sales. This enables pre-allocating the right number of server instances, Redis memory, and CDN capacity. Over-provisioning wastes money; under-provisioning crashes the sale. Accurate prediction optimizes the cost/reliability balance.

Dynamic Pricing and Discount Adjustment