High‑Availability Architecture for a Flash‑Sale System in the Weishi Spring Festival Card‑Collect Event

The article describes the design and implementation of a highly available flash‑sale (秒杀) system used in the Weishi Spring Festival "card‑collect" activity, which experienced extreme traffic spikes.

Background and challenges : The activity involved issuing cards, collecting them, and distributing rewards under massive concurrent load. Key difficulties include maintaining a smooth user experience, handling instantaneous high‑concurrency, and avoiding bottlenecks—especially at the database layer.

System analysis : The author outlines three architectural models:

Typical three‑tier internet architecture (access → logic → DB) with stateless services and horizontal scaling.

Straight‑through (direct) architecture where requests flow 1:1 to the DB, suitable only for simple services.

Funnel (漏斗) architecture that progressively filters traffic before reaching the DB, ideal for flash‑sale scenarios.

Design and implementation details :

Product strategy : Separate lightweight “grab” operations from heavyweight “settlement” operations, stagger user entry, and simplify the UI during the sale.

Client side : Define retry policies (non‑retryable vs. retryable errors), provide clear UI/UX messages, and optionally drop random requests when traffic exceeds capacity.

Access layer : Perform authentication, enforce global rate limiting (dynamic per‑machine limits, global keys with timestamps), and apply IP/user frequency control to block malicious traffic.

Logic layer : Validate parameters and eligibility early, use asynchronous order compensation (transaction rollback vs. async redo), and mitigate hot‑key issues with sharded keys.

Storage layer : Ensure DB reliability (master‑slave, cross‑region disaster recovery) and strict consistency for inventory updates.

Practical deployment : The article presents the end‑to‑end user flow, architecture diagram, and a three‑level degradation plan (automatic entry‑level throttling, backend random request dropping, and frontend random dropping) to keep the system robust during peak moments.

Reflection : The author shares thoughts on how architects can grow by building a personal knowledge graph, summarizing and sharing experiences, and continuously abstracting distributed‑system solutions.

Note: The author’s team is recruiting backend engineers (contact via the official account).