Technical Analysis of Flash‑Sale (秒杀) Systems: Scenarios, Architecture, and Lock Strategies

Business Scenario Analysis

Typical flash‑sale use cases include limited‑time product seckill, group red‑envelopes, coupon grabs, lottery draws, and train‑ticket purchases. These scenarios feature instantaneous sell‑out, extremely high concurrent requests, short activity windows, and often scheduled product releases.

Technical Characteristics

Key technical traits are read‑heavy/write‑light traffic, massive concurrency, and resource conflicts. Caching (e.g., CDN) mitigates backend pressure, while rate‑limiting, load balancing, asynchronous peak‑shaving via message queues, and atomic operations protect critical resources.

Request‑Chain Analysis

A flash‑sale request traverses the client layer, network, load‑balancer, service layer, and finally the database. Each layer offers optimization opportunities:

Client layer: cache static assets, disable the purchase button after the sale ends, and use captchas to block automated attacks.

Network layer: employ CDN for static resource acceleration.

Load layer: use Nginx for load balancing, static‑dynamic separation, reverse‑proxy caching, and rate limiting (e.g., ngx_http_limit_req_module ).

Service layer: static‑ify dynamic pages, leverage local or distributed caches, apply message‑queue‑based async throttling, and ensure atomic operations on critical data.

Database layer: implement optimistic or pessimistic locking to guarantee atomic inventory updates.

Lock Mechanisms Comparison

Optimistic lock: each request reads the current version and attempts an update conditioned on that version. Only one of concurrent requests succeeds.

SELECT version FROM goods WHERE id = 1;
UPDATE goods SET count = count-1, version = version+1 WHERE id = 1 AND version = {version};

Optimistic lock with retry: if the update fails, the request immediately retries until it succeeds.

Pessimistic lock: the row is locked before reading (e.g., SELECT * FROM goods WHERE id = 1 FOR UPDATE ), guaranteeing exclusive access for the subsequent update.

Choosing Between Optimistic and Pessimistic Locks

Consider response speed, conflict frequency, and retry cost. Optimistic locking suits low‑conflict, latency‑sensitive scenarios; pessimistic locking is preferable when conflicts are frequent or retry overhead is unacceptable.

Illustrative Example

Assume a flash‑sale of a children’s toy with 200 concurrent users and 100 items in stock. The table below shows order generation and items sold under different concurrency‑control methods:

Concurrency Control

Orders Generated

Items Sold

None

200

<100 (inconsistent)

Optimistic Lock

n (n≤100)

n (n≤100)

Optimistic Lock with Retry

100

100

Pessimistic Lock

100

100

Results demonstrate that both retry‑optimistic and pessimistic locks ensure data consistency and full inventory sell‑through, while a plain optimistic lock may leave items unsold under high contention.