How to Build a Scalable Flash‑Sale System: Isolation, Caching, and Real‑Time Hotspot Detection

1. Some Data

Remember the 2013 Xiaomi flash‑sale where three phone models sold 110,000 units each within minutes, becoming the first Double‑11 store to break 100 million sales. Log analysis showed the front‑end system peaked at over 600 k QPS, the back‑end cache cluster reached nearly 20 M requests/s, and the highest order‑reduction TPS was 1.5 k/s.

2. Hotspot Isolation

The first principle of flash‑sale system design is to isolate hotspot data so that 1 % of requests do not affect the remaining 99 %. Isolation makes targeted optimization easier. Three levels of isolation are applied:

Business isolation : Treat the flash‑sale as a marketing activity; sellers must register, making the hotspot known in advance for pre‑warming.

System isolation : Deploy flash‑sale services in separate groups and even a dedicated domain name, routing requests to distinct clusters.

Data isolation : Use dedicated cache clusters or MySQL databases for hotspot data, preventing the 0.01 % hotspot from impacting the 99.99 % normal data.

Other isolation methods include user‑based routing, URL‑path rate limiting, and tagging data with special markers.

3. Dynamic/Static Separation

After system‑level isolation, static and dynamic data are separated. Most static content is cached in the browser or CDN, while only the "refresh抢宝" button triggers a request for the latest dynamic data. This reduces the effective request volume dramatically, improving performance by more than three times compared with a normal detail page.

Additional characteristics:

Cache the entire page in the user's browser.

Force‑refresh still hits the CDN.

Only the "refresh抢宝" button generates a server request.

4. Data‑Layer Validation

Large‑traffic systems should filter invalid requests at each layer, forming a funnel where only the final layer sees genuine traffic. Validation principles include:

Perform dynamic/static separation first.

Cache 90 % of data on the client side.

Cache read‑only data on the web tier.

Do not enforce strong consistency on read data.

Apply time‑based sharding to write data.

Rate‑limit write requests.

Perform strong consistency checks on write data.

The flash‑sale architecture follows this funnel, with front‑end checks for eligibility, product status, answer correctness, and sale status, back‑end checks for illegal requests and inventory, and final database guarantees that inventory never becomes negative.

5. Real‑time Hotspot Discovery

Hotspot detection is performed within 3 seconds by collecting key statistics from middleware (Tengine, Tair, HSF, etc.) and publishing them through a hotspot service. Downstream systems subscribe to this service to receive proactive protection rules.

Key points:

Asynchronous hotspot log collection to avoid impacting main flows.

Uniform hotspot subscription protocol for all middleware.

Real‑time (≤3 s) discovery and propagation.

6. Key Technologies and Optimizations

Java handling of massive concurrent requests is weaker than Nginx/Apache, so static‑content offloading is essential. Optimizations include:

Direct Servlet handling : Bypass heavyweight MVC frameworks to save milliseconds.

OutputStream usage : Use resp.getOutputStream() instead of resp.getWriter() and prefer JSON over template rendering.

For the same product’s high‑concurrency reads, a local cache on each flash‑sale machine stores static product info, while dynamic data like inventory uses short‑lived passive invalidation.

Write‑side concurrency is addressed by:

Application‑level queuing : Queue requests per product to limit DB row lock contention.

Database‑level queuing : Use InnoDB patches (e.g., COMMIT_ON_SUCCESS, ROLLBACK_ON_FAIL) and hints to achieve global row‑level queuing, reducing lock wait times.

7. Large‑Scale Promotion Hotspot Thoughts

Summarizing the principles: isolate hotspots, separate dynamic/static data, and apply layered validation across the entire request chain. In addition to flash‑sale hotspots, other data‑hotspot scenarios include access‑hot items, update‑hot fields, and index‑hot dimensions, each requiring local caching, sharding, or migration strategies.