Backend Development 11 min read

Design and Challenges of Meizu Real-Time Message Push System

The article details Meizu's large‑scale real‑time push architecture, covering system scale, four‑layer design, mobile power‑saving optimizations, network instability handling, massive connection techniques, load‑balancing strategies, comprehensive monitoring, and gray‑release deployment practices.

Architecture Digest
Architecture Digest
Architecture Digest
Design and Challenges of Meizu Real-Time Message Push System

The presentation, originally delivered at Meizu's technical open day, describes a real‑time push system serving roughly 25 million online users, handling about 5 billion page views per day and achieving a push throughput of 600 k messages per minute.

The architecture is divided into four logical layers: device access, message distribution (including upstream routing and downstream delivery with a user routing table), subscription management, and storage for both offline and subscription messages.

Key challenges discussed include mobile power consumption, which the team addressed by designing a lightweight IDG protocol (10× faster encoding/decoding than XMPP/SIP) to reduce traffic by 50‑70 % and by implementing adaptive heartbeat intervals to lower battery drain.

Network instability in mobile environments leads to duplicate messages; the solution involves sequence‑based acknowledgments, DNS/IP fallback lists, and client‑side probing to select the optimal server, while also applying delayed responses on overloaded servers.

To support massive concurrent connections (up to 4 million long‑lived connections per machine), the system uses C++ with epoll, memory pools, tcmalloc, and kernel tuning (CPU affinity for NIC interrupts and increased TCP RTO).

Load balancing is achieved without a single LVS point by having clients fetch a prioritized IP list, probe multiple servers, and select the fastest response, complemented by server‑side latency throttling when load thresholds are exceeded.

Monitoring covers error counts, send/receive queue depths, request rates, interface latency, and service availability, with alerts to detect early signs of overload or failure.

Finally, a gray‑release process is described, allowing incremental, user‑transparent deployments and gradual traffic migration to ensure stability before full rollout.

Backenddistributed systemsmonitoringreal-time messagingload balancingGray Releasehigh concurrency
Architecture Digest
Written by

Architecture Digest

Focusing on Java backend development, covering application architecture from top-tier internet companies (high availability, high performance, high stability), big data, machine learning, Java architecture, and other popular fields.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.