Designing Scalable Flash‑Sale Architecture to Survive Traffic Surges

Business Requirements

Product information is supplied by external providers.

Multiple flash‑sale sessions run each day, each with its own product set and quantity limits.

Products must be presented to users sorted by geographic location.

System Architecture

The system is split into three logical parts:

Data layer :

Product DB – a relational database that stores the full catalog received from third‑party sources.

Flash‑Sale Plan DB – a relational table maintained by operations staff that records the schedule of each flash‑sale session and the total quantity allocated to the session.

Business layer :

Flash‑Sale DB – a NoSQL store (commonly Redis) that holds a subset of products for the current session. This DB is the source of all high‑frequency “is there stock?” queries.

Operation control (side‑track) : a lightweight UI used by operators to create/modify flash‑sale plans and to select the products that belong to each session.

Decoupling Front‑End and Back‑End Load

Build an internal product repository so that third‑party APIs are never called during a flash‑sale burst.

Separate the high‑throughput flash‑sale queries from the relational product store. All stock‑availability checks hit the Redis cache, keeping the relational DB isolated from traffic spikes.

Use Redis (or a similar in‑memory data structure) as a queue to absorb the sudden request surge and to enable horizontal scaling of business‑layer servers.

Processing Flow

Two complementary sequence diagrams illustrate the end‑to‑end flow.

From the product side the steps are:

External provider pushes product data → Data layer (Product DB).

Operations create a flash‑sale plan → Flash‑Sale Plan DB.

Selected products are copied into Flash‑Sale DB (Redis).

From the user side the steps are:

User clicks “Buy” → system checks whether the flash‑sale session is active.

If active, a high‑frequency stock check is performed against the Redis list.

When stock is available, the user is placed in a reservation queue (Redis list) and receives a reservation token.

After reservation, the user is redirected to the third‑party payment gateway.

Ensuring Inventory Consistency

Two consistency models are possible:

Strong global consistency – guarantees that every user sees the exact same decreasing inventory count, but requires distributed locking and incurs high latency.

Per‑user (monotonic) consistency – each user sees a monotonically decreasing count after they obtain a reservation. This model is cheaper and sufficient for most flash‑sale scenarios.

Implementation uses a Redis list as a queue. The list is pre‑filled with the total quantity of a product for the session. Each successful LPOP (or RPOP) removes one element and decrements the logical stock. If the list is empty, the product is considered sold out.

Transaction Data and Reconciliation

A dedicated Transaction Data store records a unique TransactionID for every user session from the moment the user enters the flash‑sale page until the redirect to the third‑party payment system. The record contains:

User identifier and location.

Flash‑sale session identifier.

Product ID and reserved quantity.

Timestamp of reservation.

Signed token that will be passed to the payment gateway.

At the end of each day a reconciliation job runs:

Export all TransactionIDs and their status (paid / unpaid).

Query the third‑party payment provider for the corresponding order list.

Compare the two sets to detect mismatches in item count or monetary amount.

Generate a correction report and optionally trigger compensating actions (e.g., refund, inventory adjustment).

Anti‑Abuse Measures

Queue‑based reservation ensures that only users who have successfully dequeued an item can proceed to payment.

Signed tokens (e.g., HMAC) are attached to the redirect URL; the payment provider validates the token before accepting the order.

Rate limiting per user ID or IP address limits the number of reservation attempts.

Per‑user purchase limits (e.g., one unit per account) are enforced by checking the Transaction Data before granting a new reservation.

CAPTCHA challenges can be inserted before the reservation step to block automated bots.