How to Build a High‑Performance Flash Sale System: Strategies & Pitfalls

Key Knowledge Points for Flash Sale Systems

A. High concurrency, cache, lock mechanisms

B. FIFO queue based on cache architectures like Redis or Memcached

C. Large‑scale flash sales require distributed clusters; JVM‑level synchronized locks are insufficient

D. Database pressure

E. Overselling problem

F. Preventing malicious users (blacklist, IP limits)

G. Using Memcached atomic operations for concurrency control

Simple Design Example

Assume 10 items are available for flash sale and are stored in cache without locking. Under heavy load, more than 10 users may succeed in the request, so only the first 10 are allowed to purchase while the rest receive a static "sale ended" page.

Typical Flash Sale Scenario

10 items, 100 web servers (Nginx + Tomcat), multiple app servers, and several databases.

Step 1 – Java‑level Filtering

Each web server maintains an AtomicInteger initialized to 10. Calls to decreaseAndGet() that return a value ≥ 0 continue processing; otherwise the request is rejected with a "sale ended" page. This reduces the request count to roughly 100 × 10 = 1000.

Step 2 – Memcached Counter

Store the inventory count (key = product ID, value = 10) in Memcached. Each request invokes decr(key,1); if the returned value is ≥ 0, processing continues, otherwise the request receives a failure page. This narrows the traffic to the fastest 10 requests among the 100 servers.

Step 3 – Order Transaction

The app server creates an order within a transaction.

Step 4 – Stock Decrement

The app server updates the database with a statement such as

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 Flash Sale Practices

Frontend Strategies

Expansion: Add more front‑end servers to increase overall capacity.

Staticization: Serve static assets via CDN and minimize dynamic content.

Rate Limiting: Apply IP‑level request limits.

Graceful Degradation: Introduce games or puzzles at the entry point to smooth traffic spikes.

Lossy Service: Randomly reject a portion of requests when the system approaches its capacity limit.

Backend Challenges

High concurrency stresses MySQL performance, leads to overselling, and causes InnoDB row‑lock contention, potentially resulting in deadlocks and timeouts.

Taobao Solutions

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 frequency.

Solution 1 – Redis Front‑loading

Shift write operations to Redis, eliminating lock contention and leveraging Redis’s superior read/write speed; asynchronously sync changes back to the database.

Solution 2 – Single Queue

Serialize all DB writes through a single queue; stop consuming when inventory is exhausted, preventing overselling.

Solution 3 – CAS in Memcached

Use Memcached’s lightweight CAS lock to perform atomic stock decrements directly in memory.

Solution 4 – Two‑Phase Commit with Redis

First reserve a stock token via Redis atomic increment, then confirm the order; asynchronously persist to the database, ensuring both performance and oversell protection.

Summary

Front‑end: expansion, rate limiting, staticization. Backend: in‑memory processing plus queuing strategies.