How Xiaomi Built the Notify Async Messaging System to Scale Its E‑commerce Platform

Xiaomi Web Architecture Evolution

To keep up with rapid business growth, Xiaomi's web system underwent several architectural changes, culminating in the creation of its own asynchronous messaging system called Notify.

1. Initial Stage

When Xiaomi launched its first phone, it adopted a direct‑sales e‑commerce model and built a simple website with a single product line, massive order volume, and huge traffic spikes. The architecture consisted of two web servers (active‑standby) and one database server, all functions bundled into one system. Development time was only two months with three engineers.

2. Development Stage

To reduce coupling, Xiaomi split the monolith into independent subsystems, creating a dedicated “big‑second” system for flash‑sale requests and adopting an SOA architecture with a custom X5 protocol for interface communication.

While this decoupling improved isolation, most interfaces remained synchronous, leading to failures when network issues occurred. The need for an asynchronous message queue became evident.

3. Mature Stage

After introducing the asynchronous message system, the architecture changed dramatically, making the message queue the central hub connecting almost all subsystems.

Notify Message System Design

Notify was built on top of Redis queues with MySQL for persistence. It solves four core problems: receiving messages, storing messages, delivering messages, and monitoring statistics.

Key data tables include:

biz – producers

receive – consumers

biz_receive – subscription relationships (status: normal, paused, discarded)

biz_msg – business messages (payload)

receive_msg – delivery records (status: pending, queued, delivered, dropped)

Notify introduces a message‑splitting mechanism that allows a single business message to be duplicated for multiple subscribers, improving scalability and configurability.

The system works as follows: business systems call the Api.notify interface, messages are stored in the DB, a Maker component creates a copy for each subscription and pushes it to a dedicated Redis MQ, and a Sender component delivers the message to the target system while updating status via a Marker service.

Notify System Upgrades

Initial versions faced issues such as direct interface delivery risking failures, a PHP‑only implementation, and a single MySQL instance limiting scalability. Improvements include:

Agent proxy: business systems write messages to a local DB; an always‑running Agent collects and forwards them, increasing reliability.

Rewriting critical modules in Go, boosting API receive capacity by 21×, Marker processing by 4×, and Sender throughput by 4×.

Introducing MyCAT for distributed MySQL storage, enabling horizontal scaling of the database layer.

Conclusion

The paper presents Xiaomi's practical experience in building an asynchronous message queue system, sharing design insights and lessons that can guide other companies in implementing robust, scalable backend messaging solutions.