Flash sale mechanics¶
Flash sale mechanics (秒殺) refers to a system architecture pattern designed to handle high-concurrency scenarios where a limited number of items are sold within a very short timeframe. This type of transaction presents unique challenges distinct from standard e-commerce operations, primarily requiring the system to manage massive traffic spikes without overselling inventory.^[600-developer__principle__spike.md]
Key Challenges¶
The primary difficulty in a flash sale lies in the extreme disproportion between traffic and inventory. Unlike typical business scenarios, a flash sale attracts a large number of users competing for a very small number of resources in a brief window.^[600-developer__principle__spike.md] This creates a "thundering herd" problem where the system must prevent overselling while maintaining responsiveness.
To address this, the architecture must prioritize consistency and high availability over eventual consistency, ensuring that the number of sold items never exceeds the available stock.^[600-developer__principle__spike.md]
System Architecture¶
Implementing robust flash sale mechanics typically involves a multi-layered caching and isolation strategy to protect the database and ensure performance.
Isolated Schemes¶
The standard practice is to isolate flash sale data from the main business database to prevent traffic spikes from affecting regular transactions.^[600-developer__principle__spike.md]
- Separate Database: A distinct database scheme is often created specifically for flash sale events^[600-developer__principle__spike.md].
- Hot and Cold Data Separation: Data is categorized into "hot" (frequently accessed, like current stock counts) and "cold" (historical transaction records)^[600-developer__principle__spike.md].
- Data Archiving: Once a flash sale concludes, the transaction data is typically migrated or archived to the standard business database^[600-developer__principle__spike.md].
Caching Strategy¶
[[redis|Redis]] is the de facto standard for handling the high-performance requirements of flash sales^[600-developer__principle__spike.md].
- Pre-heating: The system performs a "warm-up" process where inventory data is loaded into the cache before the sale begins^[600-developer__principle__spike.md].
- Inventory Deduction: Inventory reductions are executed directly in the cache (e.g., using Redis operations) rather than hitting the disk database immediately^[600-developer__principle__spike.md].
- Asynchronous Processing: User requests are often placed in a queue for background processing, reducing the immediate load on the system^[600-developer__principle__spike.md].