Master Flash Sale Systems: Boost Performance, Ensure Consistency & High Availability

Introduction

Flash sale (秒杀) is a scenario where massive concurrent requests compete to purchase the same item at the same moment. From an architecture perspective, a flash‑sale system is a three‑high system: high performance, high consistency and high availability.

Overall Thinking

The core challenges are concurrent reads and concurrent writes, which translate to requirements for high availability, strong consistency and high performance.

High Performance

1. Dynamic‑Static Separation

Separate dynamic data from static pages in three steps: data splitting, static caching, and data integration.

1.1 Data Splitting

Split user information (login state, profile) and time information from the page so they can be fetched independently.

1.2 Static Caching

Cache static data in the browser, CDN or server; CDN is preferred because it can invalidate caches within seconds and provides high hit rates while avoiding server‑side bottlenecks.

1.3 Data Integration

Combine static and dynamic data using ESI (Edge Side Includes) or CSI (Client Side Include) so that the final page is assembled either at the edge or on the client.

2. Hotspot Optimization

2.1 Hotspot Operations

Limit frequent refreshes, add captchas or other protective measures to prevent abusive operations such as rapid page refresh, rapid add‑to‑cart, etc.

2.2 Hotspot Data

Identify static hotspots (predictable hot items) and dynamic hotspots (unpredictable spikes). Collect hotspot keys asynchronously (e.g., Nginx logs, agent logs), aggregate them, and push to downstream services for isolation and optimization via caching or rate‑limiting.

2.3 Hotspot Isolation

Business isolation : separate hot‑sale items into dedicated campaigns.

System isolation : route hot requests to separate clusters or domains.

Data isolation : use dedicated cache clusters or database shards for hot items.

2.4 Hotspot Optimization

Cache hot data for long periods when possible.

Apply rate‑limiting to protect downstream services.

3. System Optimization

Reduce serialization – merge related services to cut RPC calls.

Direct output streams – pre‑encode static strings to bytes and avoid costly toString reflections.

Trim log stack traces – limit exception stack depth in high‑traffic environments.

Remove heavy frameworks – use plain servlets when framework overhead is unnecessary.

Consistency

Inventory is the key data; three common reduction methods are order‑time deduction, payment‑time deduction, and pre‑reservation.

Each method has trade‑offs between user experience and risk of malicious orders.

Typical SQL to prevent negative inventory:

UPDATE item SET inventory = CASE WHEN inventory >= xxx THEN inventory-xxx ELSE inventory END

High Availability

Traffic peaks at a single moment, so traffic shaping, answer‑questions, queuing and filtering are essential.

1. Traffic Shaping

Answer‑question to delay requests and filter bots.

Queue requests via message queues, thread‑pool locks, local buffers, or file serialization.

Filter invalid reads/writes and apply rate limits at both read and write layers.

2. Plan B

Design fallback mechanisms: multi‑region deployment, robust monitoring, graceful degradation, and rapid recovery procedures.

Summary

Designing a flash‑sale system requires balancing performance, consistency and availability through layered thinking, dynamic‑static separation, hotspot handling, database tuning, and operational safeguards.