Designing a High-Concurrency Flash Sale (Seckill) System: Architecture, Challenges, and Solutions

Background

The author revisits a previous flash‑sale article, aiming to improve it after many interview experiences that revealed common misunderstandings about seckill system details and components.

Problems

High Concurrency

Massive simultaneous requests can overwhelm servers, cause cache avalanche, cache breakdown, and cache penetration, leading to DB overload and poor user experience.

Overselling

Without proper controls, the system may sell more items than available, causing complaints, store bans, and financial loss.

Malicious Requests

Attackers can use scripts or bot farms to simulate thousands of users, increasing success rates and stressing the system.

Link Exposure

Exposed URLs allow users to pre‑fetch the seckill endpoint, bypassing intended timing controls.

Database Bottleneck

Direct high QPS to the database can cause crashes; lack of degradation, rate limiting, and circuit breaking exacerbates the issue.

Front‑End Solutions

Static resource CDN, URL salting with dynamic MD5 hashes, and both front‑end and back‑end rate limiting (including button greying and timed activation) reduce load and prevent premature requests.

Nginx

Use Nginx as a high‑performance web server and load balancer to distribute traffic across multiple Tomcat instances and mitigate malicious request spikes.

Risk Control

Implement behavior‑based risk analysis before requests reach back‑end, labeling accounts as bots and discarding suspicious traffic, effectively filtering out large‑scale automated attacks.

Back‑End Design

Adopt single‑responsibility microservices, Redis cluster with master‑slave replication, stock pre‑warming in Redis, and handle overselling with atomic operations, optimistic locks, or Lua scripts.

Transactions

Use Redis transactions, pipelines, or Lua scripts for atomic stock deduction; apply rate limiting, degradation, circuit breaking, and isolation to protect services.

Message Queue (Peak‑Shaving)

Introduce MQ to buffer burst traffic, allowing asynchronous stock updates and preventing system overload during flash‑sale spikes.

Database

Deploy a dedicated MySQL instance for seckill with proper indexing, connection pooling, and query optimization.

Distributed Transactions

Discuss TCC, eventual consistency, 2PC/3PC approaches, emphasizing trade‑offs between reliability and latency.

Conclusion

The article summarizes the key considerations and solutions for building a robust flash‑sale system capable of handling extreme traffic while maintaining data integrity and user experience.