How to Build a Scalable Flash‑Sale System that Handles Massive Traffic

1. Flash Sale Business Overview

We commonly see two types of flash‑sale business: timed flash sale and limited‑quantity flash sale. The following diagram illustrates typical cases.

Another example shows a popular limited‑edition product launch that caused site crashes due to sudden traffic spikes.

2. Flash Sale Project Design

Based on the requirement analysis we sketch a rough flow diagram.

The system is divided into two main parts: the business layer and the data layer, with an additional bypass "operation control" module. Data originates from third‑party sources.

Key data stores: Product Catalog (data layer) – stores third‑party product information. Flash Sale Plan (relational database in data layer) – created by operation control, maintains schedule and quantity for each flash‑sale session. Flash Sale Store (business layer) – a subset of the product catalog, configured by operations for each session. Transaction Data – records user‑level transaction information for later reconciliation.

2.1 Decoupling Front‑End and Back‑End Pressure

Prevent business‑side load from propagating to third‑party interfaces, avoiding a proportional increase in external request pressure.

Separate the flash‑sale store (NoSQL, e.g., Redis) in the business layer from the relational product catalog in the data layer. High‑frequency "is product available?" queries hit the fast NoSQL store, keeping the data layer insulated from traffic spikes.

Using a Redis list as a queue allows the business layer to absorb burst traffic while the data layer remains stable.

2.2 Ensuring Inventory Reliability

To provide a consistent inventory view we adopt a per‑user queuing approach. When a user obtains a slot, the stock in the flash‑sale store is decremented, guaranteeing that each user sees a monotonically decreasing count.

Implementation details:

Cache product inventory in Redis.

Use a Redis list (e.g., queue_prefix_a_id) to represent the remaining stock for product A.

If the queue length ≤ 0, the request is rejected as sold out.

If the queue length is within the allocated stock, the request waits for its turn at the head of the queue and then proceeds.

If the queue length exceeds the stock, the request is immediately rejected.

2.3 Multi‑Party Reconciliation

Each user interaction generates a Transaction ID that persists from the moment the user enters the flash‑sale flow until they are redirected to the third‑party payment page. All browsing and purchase actions are linked to this ID.

The Transaction Data store records the ID and is used for daily reconciliation with the third‑party system to resolve inventory mismatches caused by payment failures or asynchronous callbacks.

Potential causes of inconsistency include failed callbacks after payment or users abandoning the payment page after the flash‑sale store has already decremented inventory.

3. Project Summary

By isolating pressure in the business layer, employing a Redis‑based queue for inventory control, and implementing a transaction‑based reconciliation process, the design addresses the main challenges of flash‑sale systems: handling massive concurrent requests, maintaining inventory consistency, and synchronizing with external partners.