Mastering Flash Sale Systems: High-Concurrency Strategies and Real-World Solutions

Key Knowledge Points for Flash Sale Systems

High concurrency, cache, lock mechanisms

FIFO queue based on Redis or Memcached

Distributed clustering; JVM‑level locks are insufficient

Database pressure

Oversell problem

Preventing abusive users (blacklist, IP limits)

Using Memcached atomic operations for concurrency control

Simple Design Scheme

Assume 10 items are to be flash‑sold. Store the stock in cache without locking. Under heavy load, more than 10 users may succeed; only the first 10 should be allowed to purchase, the rest receive a “sold out” page.

Scenario: 100 web servers (Nginx + Tomcat), n app servers, and m databases.

First, each web server maintains an AtomicInteger initialized to the total stock (10). Requests decrement the counter; if the result is ≥0 the request proceeds, otherwise a “sale ended” page is returned. This reduces 100 × 10 = 1000 requests to the next step.

Second, a Memcached key (product‑id) holds the remaining stock (10). Each request calls decr(key,1); a non‑negative result continues, otherwise a failure page is shown. Only the fastest 10 requests across all servers reach the app layer.

Third, the app server creates an order transaction.

Fourth, the app server updates the database: UPDATE product SET count=count-1 WHERE id=? AND count>0. If the update affects one row, the order is recorded and the transaction commits; otherwise the sale fails and the user proceeds to payment.

Taobao’s Flash Sale Practices

Front‑End Strategies

Scaling: add more front‑end machines.

Staticization: serve static assets via CDN.

Rate limiting: limit requests per IP.

Lossy service: randomly reject requests near capacity.

Introduce games or puzzles at the entry point to smooth peaks.

Back‑End Challenges

MySQL performance degrades sharply after a certain concurrency level, leading to bottlenecks.

Oversell occurs because stock decrement is a transactional operation that can produce negative counts under concurrent access.

High concurrency on a single row causes InnoDB row‑lock contention, deadlocks, and timeouts.

Solutions Adopted by Taobao

Disable dead‑lock detection to improve throughput.

Move queuing logic before the storage engine to reduce engine‑level concurrency.

Batch commits to lower server‑engine interaction and I/O.

Shift writes to Redis; use its high‑performance memory store and asynchronous pipelines to persist to MySQL later. This solves performance but not oversell.

Introduce a single queue for all DB writes; stop consuming when stock is exhausted, preventing oversell. Performance limited by queue and DB write speed.

Use Memcached with CAS (compare‑and‑swap) for atomic stock decrement, achieving fast in‑memory writes with lightweight locking.

Two‑phase commit: reserve a token via Redis atomic increment, confirm later, and asynchronously sync to DB. This prevents oversell and keeps stock in memory, though data inconsistency may arise if reserved tokens are not purchased.

Summary

Front‑end “three‑pronged” approach: scaling, rate limiting, staticization.

Back‑end two main paths: in‑memory handling + queuing.