How to Build a High‑Performance Seckill System for Massive Traffic

Introduction

Many developers learn high‑concurrency theory but struggle to apply it to real projects, especially in e‑commerce flash‑sale (seckill) scenarios where purchase demand far exceeds inventory within seconds.

E‑commerce System Architecture

The typical three‑tier architecture consists of a load‑balancing layer, an application layer, and a persistence layer. Rough capacity estimates are:

Load balancer (e.g., Nginx): >100,000 concurrent connections.

Application server (e.g., Tomcat): ~800 concurrent threads.

Persistence layer: MySQL ~1,000 concurrent queries, Redis ~50,000 concurrent operations.

To raise overall throughput, common strategies include system scaling, caching, and read/write separation.

Characteristics of a Seckill System

Business Characteristics

Seckill events feature a massive, sudden surge of traffic (e.g., 618, Double‑11, 12306 during Spring Festival) with limited time, quantity, and price.

Traffic exhibits a sharp spike—"traffic burst"—where concurrent requests peak within seconds.

Technical Characteristics

Extremely high instantaneous concurrency.

Read‑heavy, write‑light: many reads of product pages, few successful purchases.

Simple workflow: typically order → decrement inventory .

Typical Synchronous Seckill Flow

The synchronous approach processes every step sequentially:

Validate captcha.

Check if the activity has ended.

Apply blacklist/anti‑scraping checks.

Verify real inventory.

Decrement cached inventory.

Calculate seckill price.

Submit order and persist to DB.

Delete seckill token.

Because the entire pipeline runs in a single request, connections remain open for the whole duration, consuming server resources and limiting scalability.

Asynchronous Seckill Design

To break the bottleneck, the workflow is split into two phases: a fast front‑end validation that quickly returns a response, and a back‑end asynchronous processing pipeline.

1. User Request

Validate captcha.

Apply rate‑limiting (e.g., based on message‑queue length).

Enqueue request to a message queue (MQ) for async handling.

2. Async Processing

Re‑check activity status.

Blacklist malicious requests.

Decrement cached inventory.

Generate a seckill token bound to the user and activity.

3. Short‑Polling Result

The client periodically polls (e.g., every 3 seconds) to see if a token has been issued, indicating a successful purchase.

4. Settlement

Validate token.

Add item to a seckill‑specific shopping cart.

Persist order to the database.

Delete the token.

This design front‑loads rate‑limiting, reduces the time a connection stays open, and allows the system to handle far higher peaks.

Redis Sharding ("暗度陈仓")

When Redis cannot sustain the required 1 million QPS, split a product’s inventory into multiple keys (e.g., 10001_0 … 10001_4) so that hash slots are distributed, increasing parallelism.

Maintain a mapping list from the original product ID to its shard keys for lookup.

Lua/OpenResty at the Load‑Balancing Layer ("移花接木")

Use Lua scripts in OpenResty to query Redis directly from the load balancer, bypassing the application layer for the most frequent read‑only checks (e.g., stock availability). This reduces the load on the application tier, which only handles the few requests that actually need further processing.

Conclusion

Effective seckill systems combine pre‑emptive rate‑limiting, asynchronous order processing, Redis sharding, and edge‑side Lua scripting to achieve the required million‑level concurrency while keeping latency low.

For further study, refer to the core skills map of concurrent programming.