Design and Analysis of a Flash‑Sale System: Architecture, Request Flow, and Lock Strategies

Business scenario analysis – Flash‑sale activities such as limited‑time product launches, group red‑packets, coupon grabs, and ticket purchases feature extremely short sales windows, massive instantaneous traffic, and a high read‑to‑write ratio.

Technical characteristics – The system must handle read‑heavy, high‑concurrency workloads, mitigate resource conflicts, and ensure atomic operations on critical resources like inventory.

Request‑chain analysis – A typical request flows from the client (static assets cached locally), through the network, to a load‑balancer (e.g., Nginx with rate‑limiting), then to the service layer (dynamic page static‑ization, local/distributed cache, async queue), and finally to the database where inventory is updated.

Lock mechanisms

1. Optimistic lock – Reads the current version field, then updates count and increments version only if the version matches. Example table definition:

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    | name | count | version |
+-------+------+-------+---------+
| 1     | toy  | 100   | 0       |
+-------+------+-------+---------+

Two concurrent requests both read version 0; only one succeeds in the UPDATE, so one purchase succeeds while the other fails.

2. Optimistic lock with retry – On failure the request immediately retries until the UPDATE succeeds, increasing the chance of a successful purchase.

3. Pessimistic lock – Uses SELECT ... FOR UPDATE to lock the row before updating, guaranteeing exclusive access.

Choosing between optimistic and pessimistic locks – Consider response speed (optimistic is faster), conflict frequency (high conflict favors pessimistic), and retry cost (high retry cost discourages optimistic‑with‑retry).

Example results – For a flash‑sale with 200 concurrent requests and 100 items, the table below shows order count and sold quantity under different concurrency‑control methods:

Concurrency control

Orders generated

Items sold

None

200

<100

Optimistic lock

n (n≤100)

n (n≤100)

Optimistic lock with retry

100

100

Pessimistic lock

100

100

The analysis demonstrates that both optimistic‑with‑retry and pessimistic locking can guarantee data consistency and full inventory sell‑out, while plain optimistic locking may leave items unsold under high contention.