Designing a Scalable Flash‑Sale System: Decoupling, Reliable Inventory, and Reconciliation

Baidu server architect Lv Yi introduces the design and implementation of a flash‑sale (抢购) system, covering business overview, architecture, and key techniques.

Business Overview

Flash‑sale services, such as limited‑time or limited‑quantity promotions, generate massive instantaneous traffic that can overwhelm backend and storage resources.

System Architecture

The solution separates the system into a data layer and a business layer, adding an “operation control” side‑channel. The data layer stores third‑party product information in a relational “product database”. The business layer maintains a “flash‑sale database” (a NoSQL cache, e.g., Redis) that holds a subset of products for each sale event.

2.1 Decoupling Front‑end and Back‑end Pressure

By creating an internal product database, the system prevents high‑frequency “is product still available?” queries from reaching the third‑party source. The business‑layer flash‑sale database handles these queries, reducing load on the data layer and allowing horizontal scaling of business servers.

2.2 Ensuring Reliable Inventory

To avoid inventory inconsistencies during spikes, the flash‑sale database uses a queue (implemented with Redis list) per product. When a user obtains a slot, the queue length is checked; if slots remain, the inventory is decremented, otherwise the request is rejected, guaranteeing a consistent per‑user view of stock.

2.3 Multi‑party Reconciliation

A TransactionData store records a TransactionID for each user session from entry to redirection to the third‑party payment page. Periodic reconciliation compares the internal transaction records with the third‑party’s consumption data, resolving discrepancies in both quantity and amount.

Project Summary

The design isolates pressure in the business layer, uses a queue‑based inventory mechanism for consistency, and employs transaction reconciliation to keep data aligned with external partners.

Q&A

Q1.1: How to prevent刷 (刷) attacks? ... A1.1: Use a queue and encrypted tokens with the payment provider; limit per‑user purchases, etc. Q1.2: Complex anti‑spam logic may hurt response time. A1.2: Keep the backend simple; rely on account systems and user consumption records. Q2: Does reconciliation compare only inventory or also amounts? A2: It compares both consumption quantity and monetary value to ensure consistency. Q3: How to prevent刷 from affecting promotion effectiveness? A3: Apply user‑ID or IP limits, require login, and enforce per‑user purchase limits. Q4: Use new captcha for each event? A4: Yes, a strong, unpredictable captcha helps mitigate automated abuse.