Inside Xiaomi Push Service: Architecture, Performance, and Lessons Learned

During the 11.11 promotion, Xiaomi Push Service sent 965 million messages, averaging 670,000 per minute, with smooth backend operation and no congestion.

Basic Technical Architecture

The service uses a protocol derived from XMPP, simplified and restructured; XMPP now serves only as a data transport layer, while each business channel (including push) transmits data in a binary Thrift format.

Server‑Side Architecture

XMPP front‑end: maintains long connections with clients via the EJabberd project and processes XMPP requests with the XMQ module. Middle layer: business logic that asynchronous‑queues messages, manages queues, and handles client commands such as registration, alias, and topic settings. HTTP front‑end: receives HTTPS requests from third‑party app servers and client account creation requests.

Data storage relies on a unified HBase cluster, with MySQL for low‑volume, complex‑filter data (e.g., topics) and an intermediate Redis cache to reduce HBase pressure.

Client Architecture

The client SDK consists of an SDK layer (exposes APIs, callbacks, and Thrift deserialization) and a PushService layer (maintains XMPP long connections and handles message send/receive). Data is passed between layers via Intents. On MIUI, the PushService layer is shared system‑wide, eliminating the need for each app to start its own service.

Feature Implementation

The service supports single‑send and batch‑send modes. Single messages can target a regID (generated from device identifiers) or an alias set by the app. Batch messages use tags; both client and server can assign tags to devices, and messages sent to a tag are delivered to all associated devices without limit.

Stability is ensured through a multi‑datacenter deployment; traffic is load‑balanced across sites and automatically fails over if a site fails. Currently two data centers are in use, with a third planned.

Security relies on a double‑encryption scheme: XMPP provides transport‑level encryption, and Thrift binary data is encrypted again before being broadcast to the app process, protecting against interception and forgery.

Performance Metrics

The system is designed to handle up to 10 million messages per minute at peak, with typical loads ranging from 400 k to 6 million messages per minute.

To cope with sudden spikes, the team employs asynchronous queuing, priority handling (broadcast messages are low priority), rate limiting, and rapid horizontal scaling by adding machines.

Refactoring History

Two major refactors occurred: (1) migration from Erlang to Java, reducing developer onboarding difficulty and increasing tooling support; (2) extensive caching at the API layer to offload frequent operations (e.g., alias and topic settings) from the backend, dramatically lowering service load.

Lessons Learned

Design services for horizontal scalability, preferably stateless, using consistent hashing for partitioning.

Prioritize comprehensive monitoring to capture load, latency percentiles, and slow logs for targeted optimization.

Avoid premature optimization; deliver functionality quickly and refine based on real‑world metrics.

Adopt agile practices with short daily stand‑up meetings to respond swiftly to changes and continuously improve the system.