Design and Analysis of Flash‑Sale (秒杀) Systems: Scenarios, Technical Characteristics, Request Chain, and Lock Strategies

Business Scenario Analysis

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

Technical Characteristics

Flash‑sale systems are read‑heavy, high‑concurrency, and prone to resource conflicts. The majority of requests are reads, while successful purchases (writes) are few. Caching (e.g., CDN) reduces backend pressure, and rate‑limiting, load balancing, asynchronous queuing, and distributed locks are essential to handle the load.

Request Chain Analysis

A flash‑sale request travels from the client to the network, then to a load‑balancing layer, onward to the service layer, and finally persists in the database. Solutions at each layer include client‑side caching of static assets, CAPTCHA protection, CDN acceleration, Nginx load balancing with static‑dynamic separation and rate limiting, service‑side dynamic page static‑ization, local or distributed caches, message‑queue based peak‑shaving, and atomic operations on critical resources.

Lock Mechanisms

Assume a goods table defined as:

CREATE TABLE `goods` (
  `id` bigint(20) NOT NULL DEFAULT 0 AUTO_INCREMENT COMMENT '商品id',
  `name` varchar(32) NOT NULL DEFAULT '' COMMENT '商品名称',
  `count` int(11) NOT NULL DEFAULT 0 COMMENT '剩余库存数量',
  `version` int(11) NOT NULL DEFAULT 0 COMMENT '版本号',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Sample data (id = 1):

+-------+------+-------+---------+
|  id  | name | count | version |
+-------+------+-------+---------+
|  1   | toy  |  100  |    0    |
+-------+------+-------+---------+

When two concurrent requests try to purchase the same item, three locking strategies behave differently:

Optimistic Lock

Each request reads the current version , then attempts an update conditioned on that version. Only one succeeds; the other fails without retry.

Optimistic Lock with Retry

If the update fails, the request immediately retries the read‑modify‑write cycle until it succeeds, increasing the chance of a successful purchase.

Pessimistic Lock

The row is locked with SELECT ... FOR UPDATE , ensuring exclusive access during the transaction.

Choosing Between Optimistic and Pessimistic Locks

Response speed – optimistic lock is faster because it avoids holding a lock.

Conflict frequency – high contention (e.g., 2000 concurrent requests for 10 items) favors pessimistic locking.

Retry cost – if retries are expensive, avoid retry‑based optimistic locking.

Small Example

Assume 200 concurrent users attempt to buy 100 toys. The table below shows order count and sold quantity for each control method:

Concurrency Control

Orders Generated

Products Sold

None

200

<100

Optimistic Lock

n (n≤100)

n (n≤100)

Optimistic Lock with Retry

100

100

Pessimistic Lock

100

100

In practice, optimistic lock without retry may leave inventory unsold, while both retry‑optimistic and pessimistic locks guarantee that all available items are sold and that order count matches sold quantity.

For reliable flash‑sale systems, estimate peak concurrency, separate the seckill service from core business, and apply appropriate locking and scaling strategies to maintain data consistency and performance.

— End of article —