Evolution of Xiaomi Web Architecture: From Monolith to Scalable Microservices and Cloud‑Native Solutions

This article, originally published in the January issue of Programmer magazine and authored by Xiaomi web architect Zhang Tao, recounts the evolution of Xiaomi Web's system architecture, drawing on insights presented at the SDCC architecture conference.

In August 2011, Xiaomi Web launched with only three developers, initially considering an off‑the‑shelf solution like ECSHOP but ultimately building a custom platform; the first‑generation architecture was a simple monolith (see Figure 1).

Figure 1: First‑generation Xiaomi Web architecture

The initial system implemented core e‑commerce components—online sales, order processing, warehousing, and logistics—sharing a single database. As traffic grew, especially during product launches, database contention became a bottleneck.

In early 2012, the team began splitting business systems, giving each service its own database, which eliminated resource contention and clarified module boundaries (Figure 2).

Figure 2: Service decomposition

As the number of subsystems increased, the inter‑service call graph became tangled (Figure 3), making maintenance increasingly difficult.

Figure 3: Interface call graph

To decouple services, the team introduced an asynchronous messaging layer called Notify, turning the mesh of calls into a star topology (Figure 4).

Figure 4: Notify asynchronous messaging system

The upgraded network architecture adopted a three‑layer model: a scheduling layer (LVS, HAProxy) for traffic routing and failover, a heterogeneous business layer (multiple languages and frameworks), and a data layer (MySQL, NoSQL, Redis, Memcache).

To handle flash‑sale traffic spikes, Xiaomi Web deployed the open‑source database middleware Cobar for horizontal sharding, running 32 instances with dual‑master high‑availability (Figure 5).

Figure 5: Cobar sharding deployment

For large‑scale flash sales, the team built the BigTap system, which works like a bank ticket machine: it validates users, grants purchase eligibility, and processes successful or failed purchases. BigTap runs on AWS, scaling up before a sale and tearing down afterward.

Figure 6: BigTap flash‑sale system

Beyond flash sales, Xiaomi Web created a high‑performance cache service (MCC) based on Redis and Twemproxy, achieving up to 140 k QPS per node and providing automatic sharding and hot‑loading. The cache service is deployed in a dual‑data‑center active‑active configuration (Figure 7).

Figure 7: Dual‑data‑center Redis cache architecture

The system also implements a virtual inventory allocation mechanism that aggregates warehouse stock into logical channels, enabling flexible distribution across sales channels and improving inventory turnover (Figure 8).

Figure 8: Virtual inventory allocation system

Monitoring is treated as a first‑class concern. The article outlines effective alerting strategies, including abnormal detection functions (val(), count(), exist(), empty()) and expressions, as well as alarm policies (times(), percent(), limit(), snooze()) to reduce noise and ensure timely response.

Finally, the team is moving toward a service‑oriented architecture built with Thrift, ETCD, Go, and PHP, with a custom Go‑based SOA framework and lightweight plugins for non‑Go services, positioning service‑orientation as the future direction.

For more architecture articles, follow the ArchDigest public account.