Mastering Flash Sale Systems: Architecture, Challenges, and High‑Concurrency Solutions

0 Series Index

Flash Sale System Architecture

1 Flash Sale Business Analysis

Normal e‑commerce flow : query product, create order, deduct inventory, update order, pay, ship.

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

2 Flash Sale Technical Challenges

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

Impact on existing services : a flash‑sale module can overload the whole site; solution: isolate the flash‑sale system with a separate domain.

High‑concurrency load on app and DB : static page caching and avoiding application server calls reduce load.

Network and bandwidth surge : a 200KB page for 10,000 users needs 2 GB bandwidth; solution: lease extra bandwidth and cache pages on CDN.

Direct order URL exposure : make the order URL dynamic with a server‑generated token released only at sale start.

Buy button activation : use a small JavaScript file that flips a flag at sale start; version the file to bypass CDN caching.

Only first order proceeds : limit each server to a small number of order attempts and use load‑balancing or cookies to reduce duplicate attempts.

Pre‑order checks :

Check per‑server processed request count; reject if >10.

Check global submitted order count; reject if exceeds product stock.

Scheduled product launch : display product but disable the purchase button until the timer expires; protect the backend with synchronized clocks.

Inventory reduction strategy : choose “deduct on click” rather than “deduct on payment” for better user experience.

Oversell problem : use optimistic locking to prevent selling more than available stock.

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

Flash‑sale bot mitigation : use verification codes, random URLs, and server‑side checks.

3 Flash Sale Architecture Principles

Intercept requests as early as possible to avoid overwhelming the backend.

Read‑heavy, write‑light workload suits caching heavily.

4 Flash Sale Architecture Design

The system is dedicated to flash sales, focusing on ultra‑fast page refresh and immediate order entry.

4.1 Front‑end Layer Design

Display a static product page with a countdown timer; static resources are served from CDN to avoid bandwidth bottlenecks.

Synchronize client time with server via a lightweight JSON endpoint.

Browser‑side request throttling: gray out the button, limit clicks per X seconds.

4.2 Site Layer Design

Limit per‑user request frequency and cache identical queries for a short window.

4.3 Service Layer Design

Use a request‑distribution module (Nginx/Apache), a pre‑processing module that checks inventory, a processing module that queues accepted requests, and a DB interface module that performs the final transaction.

User request pre‑processing module rejects excess requests early.

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

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

public class RequestQueue { public static ConcurrentLinkedQueue<HttpRequest> queue = new ConcurrentLinkedQueue<>(); }

Processor pulls requests from the queue and writes them to the DB.

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); } }

4.4 Database Design

Use a single logical database with sharding (range, hash, or router service) and grouping (master‑slave replication) to ensure availability, read performance, consistency, and scalability.

Apply optimistic locking to prevent oversell.

5 Large‑Concurrency Challenges

5.1 Request Interface Design

Separate static HTML (served by CDN) from the high‑throughput backend API; keep the API lightweight and memory‑based (e.g., Redis).

5.2 Speed Is Critical

Calculate theoretical QPS (servers × max connections ÷ response time) and understand that response time inflation under load reduces effective QPS, leading to request queuing and “snowball” failures.

5.3 Restart and Overload Protection

When overload occurs, reject traffic at the entry point before restarting services; pre‑heat caches and use graceful degradation.

6 Cheating and Defense

6.1 Single‑account burst requests

Limit each account to one concurrent request using Redis flags or a per‑account queue.

6.2 Multiple accounts from one IP

Detect high request rates per IP and present CAPTCHAs or block the IP.

6.3 Distributed IP attacks

Hard to distinguish from legitimate traffic; raise participation thresholds (e.g., account level) and use behavior‑based data mining.

7 Data Safety Under High Concurrency

7.1 Oversell Causes

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

7.2 Pessimistic Lock

Lock rows during update, but this blocks many requests and hurts QPS.

7.3 FIFO Queue

Serialize requests, but the queue can overflow under massive load.

7.4 Optimistic Lock

Use version numbers or Redis WATCH to allow concurrent attempts and only commit the first successful one.

8 Summary

Flash‑sale scenarios exemplify extreme high‑concurrency challenges; by isolating the service, leveraging caching, applying sharding, using optimistic locking, and implementing robust anti‑cheating mechanisms, a system can reliably handle tens of thousands of requests per second while maintaining data consistency and availability.