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

2014's Mi Fan Festival

In early April 2014, Xiaomi’s e‑commerce platform faced a massive traffic surge during the “Mi Fan Festival”, testing the front‑end, back‑end, logistics and after‑sales systems. The flash‑sale (抢购) system, newly rebuilt, was the first line of defense against millions of concurrent users.

How the Flash‑Sale System Was Born

After the 2011 launch of the first Xiaomi phone, the company quickly realized that traditional shopping‑cart mechanisms could not handle the explosive demand. With only one week to deliver a reliable solution, the team decided to develop an independent flash‑sale service.

1. Complete design, development, testing and launch within one week. 2. The system must run smoothly; failure is unacceptable. 3. Sale results must be reliable. 4. No overselling despite massive concurrent requests. 5. Each user may purchase only one device. 6. Provide the best possible user experience.

The design prioritized simplicity and proven technology. PHP was chosen for rapid development, and Redis was adopted as an in‑memory key/value store to avoid the bottlenecks of relational databases.

Key architectural decisions included:

Use PHP for the service layer because most developers were familiar with it.

Simplify the purchase flow to a single button that returns either “success” or “sold out”.

Minimize I/O per request.

Eliminate single‑point performance bottlenecks and enable linear scaling.

Relax strong consistency requirements and handle data asynchronously.

The core principle was to represent product availability with a simple file flag on the PHP server and log successful purchases for asynchronous processing.

Redis handled the most frequent I/O operations: checking reservations, verifying purchase success, and recording successful sales. Read‑write separation, short‑lived connections, and disabled persistence on read replicas were used to prevent Redis from becoming a bottleneck.

Second Version Flash‑Sale System

Two years later, the system was rebuilt to support multiple rounds of sales and a wider product range. The new architecture separated the flash‑sale service from the main shop, used Go for the core logic, and introduced a message‑queue‑driven workflow.

The service consists of an HTTP layer that validates URLs, filters malicious traffic, issues captchas, and enqueues requests, and a business‑logic layer written in Go that processes the queue, ensures product consistency, and returns results.

To address memory pressure in the Go HTTP server, the team custom‑built a lightweight HTTP package with a 1 KB TCP read buffer, enlarged the buffer pool to one million entries, and forced connection closure after each request, allowing the server to handle over one million stable connections.

Summary

Technical solutions must be driven by concrete problems; without a real scenario, even the most impressive technology loses value. Xiaomi’s flash‑sale systems illustrate continuous iteration, trade‑offs between consistency and availability, and pragmatic engineering to survive extreme traffic spikes.