Designing a High‑Concurrency Flash Sale (秒杀) System with Redis

What Is a Flash Sale

A flash‑sale (秒杀) scenario appears on e‑commerce sites during promotions or on ticketing platforms like 12306, where scarce or discounted items are sold in a limited quantity at a predetermined time, attracting a huge number of users to purchase simultaneously.

Flash‑Sale System Characteristics

Massive concurrent requests cause a sudden surge in traffic.

Request volume far exceeds inventory, so only a small fraction of users succeed.

The business flow is simple: place an order and decrement inventory.

Architectural Design Principles

Rate Limiting : Because only a few users can succeed, most traffic must be throttled so that only a limited portion reaches the backend services.

Peak Shaving : The system experiences a sharp traffic spike at the start of the sale; techniques such as caching and message queues are used to smooth the burst into a steady flow.

Asynchronous Processing : High concurrency is handled by converting synchronous requests into asynchronous tasks, which is essentially a form of peak shaving.

In‑Memory Caching : The main bottleneck is database I/O; moving frequently accessed data or business logic to an in‑memory cache dramatically improves performance.

Scalability : The architecture should be elastic, allowing additional machines to be added when traffic spikes, as seen in large‑scale events like Double‑Eleven on Taobao or JD.

Typical Architecture Diagram

General Flash‑Sale System Architecture

Design Ideas

Intercept requests upstream : Reduce downstream pressure by filtering most traffic at the front end.

Leverage caching : Use caches to accelerate read/write operations.

Message Queue : Queue incoming requests to smooth the load; workers pull messages at a controllable rate.

Frontend Solutions

Browser (JavaScript)

Page staticization : Render static elements and serve them via CDN to absorb peaks.

Prevent duplicate submissions : Disable the submit button after a user clicks.

User rate limiting : Restrict each user (e.g., by IP) to a single request within a time window.

Backend Solutions

Gateway Layer (Controller)

Limit request frequency per user ID (UID) to mitigate abusive traffic.

Service Layer

Even after upstream filtering, the service layer still faces massive request volume; for example, 1 million users competing for 100 phones generate at least 1 million concurrent requests.

Use a message queue to cache requests: only the limited number of successful purchase requests are forwarded to the database for inventory deduction.

Cache reads: For read‑heavy scenarios like ticket booking, cache can offload the database.

Cache writes: Move inventory data to Redis, perform decrement operations in memory, and synchronize results to the database via background jobs.

Database Layer

The database is the weakest link; upstream filtering and caching should ensure it only handles requests within its capacity.

Case Study: Implementing a Simple Flash‑Sale System with Message Middleware and Cache

Redis, a distributed cache, supports various data structures and can be used to build a powerful flash‑sale system.

Use a simple key‑value pair where an atomic integer represents the inventory limit; RPUSH inserts user IDs, and when the limit is reached, further inserts stop.

Multiple worker threads LPOP user IDs from the list and finalize orders in the database.

Redis can be replaced by other message brokers like ActiveMQ or RabbitMQ, or combined with them.

Interview Insights

Flash‑sale systems are classic short‑duration, high‑burst traffic problems. Three optimization strategies are commonly discussed:

Write to memory instead of disk.

Asynchronous processing instead of synchronous.

Distributed processing.

Redis satisfies all three, making it an ideal choice.

Why These Strategies Work

Memory over Disk : Memory is orders of magnitude faster than SSD or HDD, allowing a single server to handle loads that previously required thousands.

Critical data is still persisted at the final order stage, so no data loss occurs.

Asynchronous Processing : Convert synchronous user requests into asynchronous tasks using a message queue; this can increase effective processing capacity by thousands of times.

Distributed Processing : Scale horizontally by adding more servers; use hashing or consistent hashing (e.g., Paxos, Hash Ring) to distribute load. Redis Cluster provides a ready‑made distributed solution.

Implementing with Redis

Redis and Redis Cluster support multiple data structures and act as a high‑performance message queue. RPUSH key value Insert a flash‑sale request; stop further inserts when the limit is reached. LPOP key Workers pop successful user IDs for order processing.

Alternatively, use LRANGE key start end to read a range of IDs.

After processing each record, increment a counter (INCR key_num); when inventory is exhausted, terminate the sale and stop accepting requests.

Handling Extreme Cases

Script Attacks : Automated tools can generate massive request rates; network‑level rate limiting (e.g., Linux TC, Nginx) should be applied.

Switch Overload : Deploy multiple load‑balancing switches or use DNS‑based multi‑IP routing (CDN) to distribute traffic across several entry points.

Conclusion

With Redis Cluster, building a flash‑sale system that supports massive concurrent users becomes straightforward.

The principles described here apply to any high‑concurrency system.

Key optimization principles recap:

Write to memory instead of disk.

Use asynchronous processing.

Employ distributed processing.