Inside Xiaomi’s Push Service: Scaling to 9.65 B Messages During 11.11

Basic Technical Architecture

Protocol core : The service evolved from the MiTalk XMPP‑based protocol. XMPP now serves only as a transport layer, while each business logic unit (“channel”) runs on top. The push channel serializes data with a binary Thrift protocol.

Server‑side Architecture

XMPP Front‑end : Maintains long‑lived connections with clients using the EJabberd project and a custom XMQ module that handles Xiaomi‑specific XMPP messages.

Middle Layer : Implements business logic, asynchronous request handling, message queue management, and command processing such as registration, alias setting, and topic subscription.

HTTP Front‑end : Exposes HTTPS APIs for third‑party apps to send messages and for client devices to create accounts.

Data is persisted in a unified HBase store, with MySQL for low‑volume, complex‑filter data (e.g., topics). A Redis cache sits between the middle layer and HBase to relieve pressure.

Client SDK Architecture

The SDK consists of two layers: the public SDK layer that provides app‑level APIs and deserializes Thrift data, and the PushService layer that maintains the XMPP connection and handles send/receive. Communication between the layers uses Android Intent. On MIUI devices the PushService is shared system‑wide, eliminating the need for each app to start its own service.

Feature Implementation

Message types : Supports both single‑send (by regID or alias) and broadcast (by tag). regID is generated from IMEI + AndroidID + build serial to minimise collisions. Tags have no upper limit on device count.

Stability : Multi‑datacenter deployment with traffic evenly distributed. In case of a datacenter failure, traffic is seamlessly switched to the remaining sites. Currently two data centers are active, with a third planned.

Security : Dual‑layer encryption – XMPP transport encryption protects data in transit, while Thrift’s binary layer encrypts payloads before broadcasting to the app process, mitigating tampering and replay attacks.

Performance Metrics

Designed capacity: peak 10 million messages per minute; typical load 400 k/min, peak 6 million/min. The system is prepared for sudden 200 % traffic spikes, with measures such as asynchronous queuing, priority handling (broadcasts low priority), rate limiting, and rapid horizontal scaling.

Major Refactorings

Language migration : Originally built in Erlang, the service was rewritten in Java to leverage a larger talent pool, richer tooling, and faster development cycles.

Cache everywhere : Introduced extensive in‑process caching for frequently used API calls (e.g., alias and topic subscription) to reduce backend load.

Key Lessons Learned

Design services for horizontal scalability and statelessness, using consistent hashing when state is required.

Prioritise monitoring – collect load, request rates, percentiles, and slow logs to pinpoint bottlenecks.

Avoid premature optimisation; deliver functional features first, then optimise based on real metrics.

Adopt agile practices with short daily stand‑ups to enable rapid iteration and continuous improvement.