Designing High‑Performance, High‑Availability Flash‑Sale (秒杀) Systems: Architecture, Consistency, and Optimization

Introduction

Flash‑sale (秒杀) has become a common scenario since 2011, appearing in events like Double‑Eleven shopping and train ticket booking. It involves a huge number of simultaneous requests competing for a limited product, requiring a system that is high‑performance, highly consistent, and highly available.

Overall Thinking

The core problems are massive concurrent reads and writes, which translate to the architectural requirements of high availability, consistency, and performance. The article discusses these three aspects in three layers.

High Performance

1. Dynamic‑Static Separation

Separate dynamic data from static pages to enable caching. The three steps are data splitting, static caching, and data integration.

1.1 Data Splitting

Split user‑related data (identity, preferences) and time data (sale start time) into separate APIs.

1.2 Static Caching

Cache static data in browsers, CDN, or server side. CDN is preferred for fast, globally distributed caching with second‑level invalidation.

1.3 Data Integration

Combine dynamic data with static pages using ESI (Edge Side Includes) or CSI (Client Side Include) approaches.

2. Hotspot Optimization

Identify, isolate, and optimize hotspot operations and data. Use asynchronous collection of hotspot keys, aggregate analysis, and targeted caching or rate‑limiting.

2.1 Hotspot Identification

Distinguish static hotspots (predictable) from dynamic hotspots (unpredictable, e.g., live‑stream promotions).

2.2 Hotspot Isolation

Isolate hotspots at business, system, and data layers to prevent 1% hot traffic from affecting the remaining 99%.

2.3 Hotspot Optimization

Apply caching for hot data and rate‑limiting to protect the backend.

3. System Optimization

Reduce serialization, output raw byte streams, trim stack traces, and even remove heavyweight frameworks when extreme performance is required.

Consistency

1. Inventory Reduction Methods

Order‑time reduction (deduct inventory when order is placed).

Payment‑time reduction (deduct when payment succeeds).

Pre‑reservation (reserve inventory for a short window, then release).

2. Problems with Inventory Reduction

Order‑time reduction offers the best user experience but is vulnerable to malicious orders; payment‑time reduction prevents abuse but harms UX; pre‑reservation balances both but still faces abuse.

3. Practical Implementation

Commonly use pre‑reservation combined with anti‑fraud measures (user tagging, purchase limits, request throttling). To avoid overselling, enforce non‑negative inventory via transaction checks, unsigned integer fields, or conditional SQL.

UPDATE item SET inventory = CASE WHEN inventory >= xxx THEN inventory-xxx ELSE inventory END

Consistency Performance Optimization

Separate read‑side validation (eligibility, product status) from write‑side consistency checks. Use distributed caches for reads and apply layered validation to filter invalid requests early.

Write‑Side Optimizations

Consider alternative DB choices (e.g., Redis with persistence) for simple inventory updates, or optimize MySQL by using row‑level locks, distributed locks, or InnoDB patches such as COMMIT_ON_SUCCESS and ROLLBACK_ON_FAIL.

High Availability

1. Traffic Shaping

Introduce answer‑questions, queuing, and filtering to smooth the spike at the exact start time.

1.1 Answer Questions

Require users to solve a small quiz, which delays bots and spreads the request window.

1.2 Queuing

Use message queues or local buffers to convert synchronous calls into asynchronous processing, acknowledging the trade‑offs of latency and ordering.

1.3 Filtering

Apply layered rate‑limiting, caching, and write validation to drop invalid traffic early.

2. Plan B (Fallback)

Design a comprehensive fallback strategy covering architecture, coding, testing, release, operation, and incident response phases.

3. Operational Practices

Regular load‑testing and capacity baselines.

Runtime degradation, rate‑limiting, and circuit‑breaker controls.

Monitoring, alerting, and rapid recovery tooling.

Personal Summary

A flash‑sale system can be built incrementally from simple to complex architectures, balancing trade‑offs across performance, consistency, and availability. The article provides a concise checklist for architects to keep the main goals in focus.