How to Build a High‑Concurrency Flash Sale System: Architecture, Challenges & Solutions

Flash Sale Business Analysis

Normal e‑commerce flow: query product, create order, reduce stock, update order, pay, ship.

Flash‑sale characteristics: low price, massive promotion, instant sell‑out, scheduled launch, short duration, high concurrent requests.

Technical Challenges

Impact on existing services – isolate the flash‑sale system, optionally use a separate domain.

Application and database load under high concurrency – static product page, avoid hitting application servers; cache the page.

Sudden bandwidth increase – cache pages in CDN and rent extra bandwidth for the event.

Prevent direct order URL access – generate order URL with a server‑side random token that is only valid after the sale starts.

Control purchase button activation – use a JavaScript file that toggles a flag and injects the order URL with token; version the JS to bypass CDN cache.

Allow only the first successful order – limit each server to a small number of order requests, use cookies or a least‑connection load‑balancing algorithm.

Pre‑sale checks – reject requests when the global submitted order count exceeds the limit, otherwise forward to the order subsystem.

Architecture Principles

Intercept requests as early as possible, keep read‑heavy traffic in cache (read‑many/write‑few pattern), and design the system to be stateless and horizontally scalable.

Architecture Design

The flash‑sale system is separate from the regular e‑commerce site; the product page shows a countdown, the purchase button is gray until the sale starts, and the order form allows only one item with default address and payment settings.

Two phases are defined: the preparation phase (waiting for the start) and the sale phase (processing orders).

Frontend Layer

Display the flash‑sale product page with a countdown; static resources are stored on CDN to reduce bandwidth pressure.

Use client‑side time sync with the server to handle clock drift.

Site Layer

Limit repeated clicks on the purchase button and throttle requests per user within a short interval.

Service Layer

Use a request queue (e.g., ConcurrentLinkedQueue or ArrayBlockingQueue) to buffer incoming order requests, then process them sequentially to ensure only one order succeeds.

package seckill;
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.ConcurrentLinkedQueue;
public class RequestQueue {
    public static ConcurrentLinkedQueue<HttpRequest> queue = new ConcurrentLinkedQueue<>();
}

Pre‑processor checks product availability and either enqueues the request or rejects it.

public class PreProcessor {
    private static boolean reminds = true;
    public static void preProcess(HttpRequest request) {
        if (checkReminds()) {
            RequestQueue.queue.add(request);
        } else {
            forbidden();
        }
    }
}

Database Design

Use sharding (horizontal partitioning) and grouping (master‑slave replication) to ensure scalability and availability.

Three routing methods: range, hash, and router‑config‑server.

Read‑heavy workloads benefit from caching; write‑heavy workloads use dual‑master (one active, one shadow) for high availability.

High‑Concurrency Challenges

Design request interfaces to be fast, use in‑memory stores like Redis for quick checks, and avoid direct MySQL writes under peak load.

Monitor QPS, response time, and implement overload protection at the entry point.

Cheating Prevention

Limit one request per account, detect high‑frequency IPs, use captchas or block IPs, and set participation thresholds to filter zombie accounts.

Data Safety Under Load

Prevent overselling by using optimistic locking (e.g., Redis WATCH) or FIFO queues; avoid pessimistic locks that degrade performance.

Summary

Flash‑sale systems require careful isolation, static page caching, request throttling, queue‑based order processing, sharded and replicated databases, caching layers, and robust consistency mechanisms such as optimistic locks to handle massive concurrent traffic while maintaining data integrity.