How Xiaomi Engineered a High‑Performance Flash‑Sale System for the 2014 Mi Fan Festival

2014 Mi Fan Festival

In the early hours of April 9, 2014, the Xiaomi team performed final checks and rehearsals for the most important e‑commerce event of the year, the "Mi Fan Festival". The event served as a stress test for the entire system, from front‑end and back‑end services to warehousing, logistics, and after‑sales support.

At 10:00 am, millions of users flooded the site, and the newly‑developed flash‑sale system faced its first real‑world high‑traffic test. Within minutes the popular items sold out and the system proved it could sustain the load.

How the Flash‑Sale System Was Born

After Xiaomi's first phone launch in August 2011, the company quickly realized that the existing e‑commerce platform could not handle the massive spikes caused by flash sales. Traditional optimizations—adding bandwidth or servers—were insufficient for the sudden tens‑of‑times traffic increase.

The team decided to build an independent flash‑sale system within one week, with strict requirements:

Complete design, development, testing, and deployment in one week.

Zero tolerance for failure; the system must run smoothly.

Accurate and reliable sale results.

Prevent overselling despite massive concurrent requests.

Each user may purchase only one device.

Provide the best possible user experience.

Given the time pressure, the team chose the simplest, most proven technology: PHP for the service layer and Redis for fast key/value storage, sacrificing strong data consistency in favor of availability and partition tolerance (CAP theorem).

First‑Version Architecture

The PHP servers used a file‑based flag to indicate whether a product was sold out. When a request arrived, the program checked the user's reservation status, whether the user had already succeeded, and the existence of the flag file. Successful purchases were logged asynchronously and later imported into the main shop system.

Redis stored user‑specific data (UID → status string) because it offers in‑memory speed, simple key/value semantics, and reliable master‑slave replication. Read operations were directed to slave instances, while writes were funneled through a single controlling process to avoid bottlenecks. Persistent writes were minimized to prevent latency spikes during the flash‑sale peak.

Second‑Version System (2014)

Two years later, the platform needed greater flexibility for multi‑round, multi‑product flash sales. The new system was rebuilt with Go for the core logic, while still isolating the flash‑sale service from the main shop.

The architecture consists of an HTTP layer and a business‑logic layer, communicating via message queues. The HTTP layer validates URLs, filters malicious traffic, provides captchas, and enqueues requests. The business layer processes the queue, applies the sale rules, and returns results.

Key improvements included a custom Go HTTP package that reduced per‑request memory from 8 KB to 1 KB, enlarged the buffer pool to one million entries, and forced connection closure after each request to avoid keep‑alive‑induced memory bloat. These changes allowed the front‑end servers to sustain over one million concurrent connections.

Conclusion

Technical solutions must be driven by concrete problems; without a real‑world scenario, even the most sophisticated technologies lose value. Xiaomi's flash‑sale systems illustrate continuous iteration, pragmatic trade‑offs, and the importance of aligning architecture with performance and reliability goals.