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

1 Flash Sale Business Analysis

Normal e‑commerce flow includes querying the product, creating an order, decreasing inventory, updating the order, processing payment, and seller shipping.

Flash Sale Characteristics

Low price

Heavy promotion

Instant sell‑out

Usually scheduled launch

Short duration with extremely high concurrency

2 Flash Sale Technical Challenges

Assuming a single product attracts 10,000 participants, the system must handle 10,000 concurrent requests. Major challenges include:

1 Impact on Existing Services

The flash‑sale activity, with its short duration and massive traffic, can overload the existing site and cause a complete outage.

Solution: Deploy the flash‑sale system independently, possibly on a separate domain, to isolate it from the main site.

2 High Concurrency Load on Application and Database

Users continuously refresh the page before the sale starts, generating massive requests that would normally hit the application server and database, causing severe load.

Solution: Redesign the flash‑sale product page to be static, bypassing the application service.

3 Sudden Increase in Network and Server Bandwidth

A 200 KB product page for 10,000 concurrent users requires about 2 GB of bandwidth, far exceeding normal usage.

Solution: Purchase additional bandwidth from the ISP and cache the product page on a CDN, renting extra egress bandwidth as needed.

4 Direct Order URL Exposure

If the order URL is known before the sale starts, users can bypass the flash‑sale timing.

Solution: Dynamically generate the order URL with a server‑side random token that becomes valid only at the start of the sale.

5 Controlling the Purchase Button State

The button should be gray before the sale and become active at the start without overloading the server.

Solution: Use a small JavaScript file that holds a flag indicating whether the sale has started; update the file at the sale start and let browsers load it with cache‑busting versioning.

6 Allow Only the First Successful Order to Reach the Order Sub‑system

Only one user should succeed; subsequent requests must be rejected.

Solution: Limit each server to a small number of order attempts and use load‑balancing strategies to reduce contention.

7 Pre‑order Checks

Each server checks the number of processed orders locally and globally before allowing a new order.

If local count exceeds 10, return a sold‑out page.

If global count exceeds total stock, return a sold‑out page; otherwise forward to the order subsystem.

8 Timed Product Release

Set the product’s launch time in advance; the page shows the product but disables the “Buy Now” button until the sale starts.

9 Inventory Reduction Strategies

Two approaches: reduce inventory on order placement or on payment. The “reduce on order” method offers better user experience.

10 Preventing Oversell

Concurrent updates can cause sales exceeding stock.

Solution: Use optimistic locking.

update auction_auctions set quantity = #inQuantity# where auction_id = #itemId# and quantity = #dbQuantity#

Alternatively, attempt to decrement inventory only if sufficient stock remains:

update auction_auctions set quantity = quantity-#count# where auction_id = #itemId# and quantity >= #count#

11 Dealing with Bots

Use secure verification codes, TV‑displayed codes, or quiz‑style captchas to block automated purchase scripts.

3 Flash Sale Architecture Principles

Intercept requests as early as possible; most traffic should be filtered before reaching the backend data layer.

Adopt a read‑heavy, write‑light pattern and leverage caching heavily.

4 Flash Sale Architecture Design

4.1 Front‑end Layer

Display the flash‑sale product page with a countdown timer. Static resources (HTML, CSS, JS, images) must be stored separately and served via CDN to avoid bandwidth bottlenecks.

4.2 Site Layer

Limit each user ID to one request within a short interval and cache the page for repeated accesses, effectively filtering 99% of traffic.

4.3 Service Layer

Use a request queue to pre‑process incoming requests. Example pre‑processor code:

package seckill;
import org.apache.http.HttpRequest;
public class PreProcessor {
    private static boolean reminds = true;
    public static void forbidden() { /* Do something */ }
    public static boolean checkReminds() {
        if (reminds) {
            if (!RPC.checkReminds()) {
                reminds = false;
            }
        }
        return reminds;
    }
    public static void preProcess(HttpRequest request) {
        if (checkReminds()) {
            RequestQueue.queue.add(request);
        } else {
            forbidden();
        }
    }
}

Choose a high‑performance concurrent queue (e.g., ConcurrentLinkedQueue) for request buffering.

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

Processor sends successful bids to the database:

package seckill;
import org.apache.http.HttpRequest;
public class Processor {
    public static void kill(BidInfo info) { DB.bids.add(info); }
    public static void process() {
        BidInfo info = new BidInfo(RequestQueue.queue.poll());
        if (info != null) { kill(info); }
    }
}
class BidInfo { BidInfo(HttpRequest request) { /* Do something */ } }

Database module uses a bounded queue to store potential successful bids:

package seckill;
import java.util.concurrent.ArrayBlockingQueue;
public class DB {
    public static int count = 10;
    public static ArrayBlockingQueue<BidInfo> bids = new ArrayBlockingQueue<>(10);
    public static boolean checkReminds() { return true; }
    public static void bid() {
        BidInfo info = bids.poll();
        while (count-- > 0) {
            // insert into Bids table
            info = bids.poll();
        }
    }
}

5 Challenges of Massive Concurrency

5.1 Reasonable Interface Design

Static HTML is served via CDN; the critical bottleneck is the backend API, which must be ultra‑fast and preferably operate on in‑memory stores like Redis.

5.2 Need for Speed

High QPS (e.g., 50k requests per second) can increase average response time, reducing effective throughput and causing request backlogs.

5.3 Restart and Overload Protection

When overload occurs, reject traffic at the entry point before restarting services; use graceful degradation instead of immediate restarts.

6 Cheating Techniques and Defenses

6.1 Multiple Requests from a Single Account

Limit each account to a single concurrent request using Redis with optimistic locking.

6.2 Multiple Accounts Sending Many Requests

Detect high request rates from a single IP and either present a captcha or block the IP.

6.3 Distributed IPs and Zombie Accounts

Apply higher participation thresholds (e.g., account level) and use behavior‑based data mining to filter out suspicious accounts.

7 Data Safety Under High Concurrency

7.1 Causes of Oversell

Concurrent reads of remaining stock can all see the same value and all succeed, leading to overselling.

7.2 Pessimistic Locking

Lock the stock row during update, but this can cause severe contention and timeouts under massive load.

7.3 FIFO Queue Approach

Queue requests and process them sequentially, but the queue can grow unbounded and exhaust memory.

7.4 Optimistic Locking

Use version numbers or Redis WATCH to ensure only one request succeeds; others receive a failure response.

8 Summary

Flash‑sale and flash‑purchase are typical high‑concurrency scenarios in modern e‑commerce. Although specific technical solutions vary, the underlying challenges—traffic spikes, data consistency, overload protection, and anti‑cheating—are common, and the presented principles and patterns provide a solid foundation for building robust, scalable systems.