How a Message Queue Keeps Flash‑Sale Systems Stable Under 10k Orders per Second

When a flash‑sale (秒杀) event starts, it can generate up to 10,000 order requests per second, while a typical database may only sustain about 500 writes per second. Directly writing each request to the database would cause the service to crash and present a white‑screen to users.

Step 1 – Peak Shaving: Using the Queue as a Buffer

All incoming requests are first placed into a message queue, which acts like a large water bucket. Consumers then pull tasks from the queue at a rate the database can handle, smoothing the traffic spike and preventing overload.

Step 2 – Asynchronous Acceleration: Keeping the Main Flow Light

A typical order flow includes creating the order, issuing coupons, adding points, and notifying logistics. If all steps are executed synchronously, the response time can reach 500 ms, which is unacceptable in a flash‑sale scenario.

By offloading the non‑critical tasks (coupon issuance, point addition, notifications) to the message queue, the main flow only creates the order and immediately returns a success response. This reduces perceived latency from 500 ms to about 50 ms.

Step 3 – System Decoupling: Preventing Cascading Failures

Without a queue, the order service must synchronously call downstream services such as points or analytics. If any downstream service fails, the entire order flow breaks—a classic strong‑coupling problem.

Introducing a message queue breaks this tight coupling: the order service merely publishes a message, while downstream services independently consume it. If, for example, the analytics service is down, the order service continues to operate and messages remain in the queue until the analytics service recovers.

Practical Template: The Three‑Blade Framework for Flash‑Sale Queues

Peak Shaving : Request burst → Queue buffer → Steady consumption based on DB capacity. Formula: Queue depth = Peak QPS × Duration – Consumption rate × Duration.

Asynchronous Processing : Main flow returns within ~50 ms; auxiliary tasks (coupon, points, notification) are enqueued for later handling.

Decoupling : Upstream and downstream communicate via the queue; failures in one component do not affect the other, and messages are retained until processed.

Applying these three principles lets a system absorb traffic spikes, respond quickly, and avoid crashes.

Conclusion

A message queue is not a universal cure; it introduces latency, potential message loss, and duplicate consumption. However, for flash‑sale scenarios characterized by instantaneous traffic explosions, it serves as the most reliable protective layer.