Design and Optimization of High‑Concurrency Flash‑Sale (秒杀) Systems

Flash‑sale (秒杀) scenarios have become ubiquitous since 2011, involving massive simultaneous requests to purchase limited items. From an architectural perspective, a flash‑sale system must satisfy three core requirements: high performance, strong consistency, and high availability.

Overall Thinking

The problem can be broken down into three layers: high read concurrency, high write concurrency, and high availability. Each layer drives specific design decisions.

1. Dynamic‑Static Separation

Static pages are cached while dynamic data (user info, current time) is fetched on demand. The three steps are:

Data splitting – isolate user and time data.

Static caching – store static HTML in browsers, CDNs, or servers.

Data integration – combine static and dynamic parts using ESI or CSI.

1.1 Data Splitting

User identity and flash‑sale timing are separated from the page content and retrieved via asynchronous requests.

1.2 Static Caching

Caching can be performed in the browser, CDN, or server. CDNs are preferred for large‑scale traffic, but must support second‑level invalidation and high hit‑rate.

1.3 Data Integration

Two integration methods are used:

ESI – the edge server injects dynamic data into static pages (better UX, higher server load).

CSI – the client fetches dynamic data via JavaScript (lighter server load, slightly worse UX).

2. Hotspot Optimization

Hotspots include both hotspot operations (e.g., rapid refresh, add‑to‑cart) and hotspot data (frequently accessed inventory). The three‑step process is identification, isolation, and optimization.

2.1 Hotspot Identification

Static hotspots are predictable (e.g., pre‑selected popular items), while dynamic hotspots emerge unpredictably (e.g., live‑stream promotions).

2.2 Hotspot Isolation

Isolation can be performed at the business level (separate flash‑sale sign‑up), system level (dedicated clusters or domains), or data level (dedicated cache or DB shards).

2.3 Hotspot Optimization

Typical techniques are:

Cache hotspot data (long‑term static cache).

Rate‑limit requests to protect downstream services.

3. System Optimization (Code‑Level)

Key performance tweaks include reducing serialization, using raw output streams, trimming stack traces, and removing heavyweight frameworks when possible.

4. Consistency – Inventory Reduction

Three common inventory‑deduction methods are:

Deduct on order creation (most accurate but vulnerable to malicious orders).

Deduct on payment (prevents abuse but may cause over‑ordering).

Pre‑reserve inventory (reserve for a limited time, then release if unpaid).

SQL example for safe deduction:

UPDATE item SET inventory = CASE WHEN inventory >= xxx THEN inventory-xxx ELSE inventory END;

5. High Availability

Flash‑sale traffic forms a sharp spike at a single moment, requiring traffic‑shaping techniques such as answer‑questions, queuing, and request filtering.

5.1 Traffic Shaping

Answer‑question challenges to delay requests and deter bots.

Queueing via message queues, thread‑pool locks, or local buffers.

Filtering at read/write layers (rate‑limit, cache, validation).

5.2 Plan B

A fallback plan includes multi‑region deployment, graceful degradation, robust monitoring, and rapid recovery procedures.

Conclusion

Designing a flash‑sale system involves trade‑offs among performance, consistency, and availability. By applying dynamic‑static separation, hotspot handling, careful inventory management, and comprehensive high‑availability engineering, engineers can build systems that reliably handle massive, bursty traffic.