Designing a Funnel Model for Flash‑Sale Architecture

Flash‑sale scenarios face a natural contradiction: millions of users compete for only a few hundred items, meaning most requests are invalid. Sending all requests to the database would cause immediate collapse, so the funnel model aims to filter out invalid traffic as early as possible.

The outermost layer uses CDN and static content delivery. Page assets such as product images, rules, and countdown timers are served directly from CDN nodes, eliminating the need for backend processing for roughly 80% of traffic.

The second layer is gateway rate limiting. A configurable threshold (e.g., 5,000 requests per second) is set; excess requests receive an immediate “activity too hot” response, regardless of whether they are real users or bots.

The third layer performs lightweight business‑level validation using Redis. Checks include whether the activity has started, if the user has already purchased, blacklist status, and token validity. Redis’s low latency filters out duplicate and illegal requests before they reach deeper services.

The fourth layer validates inventory, again using Redis rather than the database to avoid costly hits. If stock is depleted, the request is rejected; otherwise it proceeds.

The innermost layer is the database, which now only processes the final order persistence, keeping load fully controllable.

The essence of the funnel is cost pre‑placement: CDN responses cost near zero, Redis operations are cheap, while database operations are expensive. By blocking the bulk of traffic with inexpensive resources, the expensive layer handles only genuine orders.

Beyond spatial filtering, the funnel also employs temporal traffic shaping. For example, a random delay of 0–3 seconds spreads millions of simultaneous page refreshes over a time window, and captchas further stretch request arrival, converting a spike into a manageable flow.

Designing the funnel requires careful threshold setting based on load‑test data to balance false positives against backend overload. Synchronization between layers is crucial; when Redis indicates stock exhaustion, the gateway should tighten its rate limit to prevent wasted processing downstream.

Overall, the funnel model unifies seemingly independent techniques—CDN, rate limiting, Redis pre‑allocation, message queues—into a cohesive architecture that maximizes throughput while protecting critical resources.