Designing Lossless Flash‑Sale Systems: High‑Concurrency Architecture & Isolation Strategies

Preface

Flash‑sale events generate traffic spikes that can be orders of magnitude larger than normal loads. Designing a flash‑sale system provides a concrete case study for high‑concurrency architectures and the trade‑offs involved.

Lossless Technical Solutions

Divert traffic to separate streams, isolating risk.

Buffer the surge in a cache or queue and release it gradually.

Widen the processing path and remove bottlenecks through multi‑level caching and optimized inventory deduction.

System Isolation

Flash‑sale traffic is isolated into a dedicated subsystem, which can be implemented in two ways:

Physical isolation : Deploy an independent domain name and a dedicated Nginx cluster. This isolates the bulk of traffic from the core transaction system, allows independent scaling of Nginx and downstream services, and enables custom anti‑fraud logic without affecting the main system.

Logical isolation : Reuse the existing transaction cluster and apply traffic‑shaping mechanisms such as:

Rate‑limiting (e.g., limit TPS to 100 and concurrent connections to 20 for requests originating from the flash‑sale BFF).

RPC grouping – tag a subset of service nodes as “flash‑sale group” and route flash‑sale BFF traffic only to those nodes. This reduces the number of affected nodes but increases the risk of overload if a node fails.

Typical request chain:

DNS->Gateway->Frontend/Backend

Multi‑Level Caching

DNS Layer

Static assets are placed on a CDN. Users first hit local caches; if missing, the request is routed to the nearest CDN node, which serves cached content or fetches it from the origin.

Gateway Layer

The gateway may consist of an external load balancer (e.g., ISV) and an internal Nginx. Cache effectiveness depends on the load‑balancing algorithm:

Round‑robin distributes requests evenly but may send the same cache key to different Nginx instances, lowering hit rates.

Consistent hashing routes the same key to the same Nginx, improving hit rates but can create hotspot overload. A hybrid approach can switch to round‑robin when a node exceeds a threshold.

Because accurate hot‑key traffic estimation is difficult, a simple round‑robin combined with a centralized in‑memory cache is often the most pragmatic choice.

Service Layer

Application‑Nginx->Flash‑sale BFF->Order Service

Both the application Nginx and the BFF perform load‑balancing and may use local caches; the main difference lies in cache granularity and technology stack.

Cache Invalidation

Multi‑level caches make invalidation complex. Common approaches include:

Listening to database binlog changes at each layer and evicting related keys.

Broadcasting invalidation messages to all nodes, which can cause a “message storm” for frequently changing hot keys.

Lossless Peak Shaving

Scaling out alone is costly and may hit other bottlenecks (e.g., service discovery storms, bandwidth limits). Two lossless techniques are highlighted:

Asynchronous message queues (MQ) that buffer spikes and allow downstream services to consume at a steady rate.

CAPTCHA or Q&A challenges that spread user actions over time and deter bots.

MQ Asynchronous Consumption

MQ provides three essential properties:

Buffering – messages accumulate in the queue, acting as a reservoir.

Steady consumption – downstream services process messages at a controlled rate.

At‑least‑once delivery – ensures eventual consistency.

Example: 1 million concurrent order requests can be reduced to ~64 concurrent connections for the order service when routed through an MQ, dramatically shrinking the required cluster size and improving stability.

CAPTCHA / Q&A

Implementation steps for a 6‑digit CAPTCHA:

Generate a random 6‑character string and store it in Redis with a 5‑second TTL using a user‑specific key.

Create an image containing the string and return it to the client.

When the user submits the code, compare it with the Redis value; delete the key regardless of success to prevent replay attacks.

Q&A follows the same flow but uses a pre‑generated question‑answer pool. Both methods smooth traffic peaks but add latency, which may affect user experience.