Design and Evolution of Xiaomi’s Flash‑Sale System for the 2014 Mi Fan Festival

Author Han Zhupeng, a programmer at Xiaomi, describes his experience designing and operating the flash‑sale system for Xiaomi’s e‑commerce platform, especially during the 2014 Mi Fan Festival.

On the night of April 9, 2014, the team performed final checks before the festival’s traffic peak, where millions of users would simultaneously access the site. The newly built flash‑sale system, still fresh in production, faced its first real stress test.

The first version was born out of a crisis in 2011 when the initial open‑sale model overwhelmed the servers, causing database deadlocks and poor user experience. With only one week to deliver a reliable solution, the team set strict goals: rapid development, zero failure tolerance, reliable results, no overselling, one phone per user, and good user experience.

To meet these constraints, they chose the simplest, most proven technology—PHP for the backend and Redis for in‑memory key/value storage—sacrificing strong consistency in favor of availability and partition tolerance, as dictated by the CAP theorem.

The system’s core principle was a file‑based flag indicating whether a product was sold out. PHP handled purchase requests by checking user eligibility, the sold‑out flag, and logging successful purchases. Logs were sent asynchronously to a central node for counting.

Redis was used to store user reservations and purchase status because it offers fast in‑memory access, simple key/value semantics, and reliable replication. Read operations were directed to slave nodes, while writes were funneled through a single master process to avoid bottlenecks. The team also disabled persistence on read‑only slaves to prevent latency spikes.

Approximately 30 servers (20 PHP, 10 Redis) powered the first version, which successfully withstood the festival’s load.

Two years later, the system was rebuilt as the second version to support multiple rounds of flash sales and a wider product range. The new architecture emphasized flexibility and operability, separating the flash‑sale service from the main e‑commerce platform and using Go for the core processing.

In the second version, the HTTP layer validates URLs, filters malicious traffic, provides captchas, and enqueues requests. The business layer, written in Go, consumes these queues, processes purchase logic, and returns results. Message queues connect the two layers, and product inventory is kept consistent by a dedicated server process.

Performance issues in the Go HTTP server—excessive memory usage, GC pressure, and keep‑alive connections—were addressed by customizing the HTTP package: reducing TCP read buffer to 1 KB, expanding the buffer pool to one million objects, and explicitly closing connections via the "Connection: close" header. These changes allowed the HTTP front‑end to handle over a million concurrent connections.

The second version successfully passed the 2014 Mi Fan Festival, confirming the importance of tailoring technology to concrete problems and continuously iterating on system design.

Copyright notice: Content sourced from the internet; original author and source are credited. Any infringement should be reported for removal.

Figure 1 – First‑version flash‑sale system diagram

Figure 2 – Overall structure of the second‑version system

Figure 3 – Detailed architecture of the second‑version system