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

When interviewing for a technical position, candidates are often asked to design a high‑performance flash‑sale (秒杀) system, which touches almost every backend domain such as client, network, load balancing, CDN, caching, database, and more, making it an excellent test of breadth and depth.

Flash‑sale characteristics : sudden traffic spikes at a fixed start time, extremely short duration, limited inventory, and the need to control concurrency to avoid overselling.

Challenges : risk isolation from regular services, high load on databases due to frequent refreshes, URL randomization to prevent direct order page access, and bandwidth estimation for static resources.

Architectural principles : minimize data transferred, reduce request count, shorten request paths, limit dependencies, and eliminate single points of failure by stateless design.

Product layer : keep the page simple, enable the purchase button only when the sale starts, and restrict order form fields to a single quantity with default address/payment.

Front‑end layer : separate static resources and serve them via CDN, obtain real‑time countdown from the backend, gray out the button before the sale, and prevent duplicate submissions within a short interval.

Back‑end layer : use Nginx/Apache for request distribution, pre‑process requests to check inventory, handle successful requests as transactions, and expose a single database RPC interface for stock queries.

Database design : employ sharding (range, hash, or router‑config service) to handle large data volumes and ensure balanced load.

Inventory oversell prevention : apply pessimistic locking (exclusive lock) or optimistic locking (version number) to guarantee a single successful purchase per item.

Stability measures : implement graceful restart, overload protection, and reject traffic at the entry layer when the system is saturated.

Risk control : detect and block bot traffic, limit request frequency per account/IP, use captchas, and filter zombie accounts.

Asynchronous ordering : introduce a queue (e.g., Redis List) between the front‑end and order service, return a queue number to the user, show a waiting page with progress, and process orders FIFO to smooth spikes.

High‑availability construction : apply degradation, rate‑limiting, and outright request rejection when CPU or load thresholds are exceeded, often via Nginx 503 responses.