How Meizu Optimized Cloud Sync: Architecture, Protocols, and Performance Insights

Business Scenarios

Meizu's cloud sync service started with early phone models (M8, M9) and evolved through the MX system, keeping the user interface stable while dramatically changing the underlying protocols and infrastructure to support features such as device location, photo capture, and cross‑device data sharing.

Core Sync Protocols

The service supports a wide range of sync use‑cases, including cloud photo albums, backups, and file synchronization. The design distinguishes between structured and unstructured data, further splitting structured data into "typical" and "small" categories to tailor protocols for different workloads.

MZ‑SyncML Protocol Based on the Microsoft SyncML standard, Meizu introduced a compact JSON format (variables reduced to 1‑2 characters) and optional Gzip compression, achieving roughly a 70% reduction in bandwidth compared with traditional JSON (e.g., 100 M → 30 M). The server stores additional fields such as ServerAnchor and Updatetime to handle time‑drift between client and server.

Semi‑Sync Protocol Designed to resume partially completed syncs, this protocol adds a SemiAnchor field on both client and server, allowing the client to skip already synchronized items after a failure, effectively providing a breakpoint‑resume capability.

One‑Sync Protocol Targeted at small‑data scenarios where the full MZ‑SyncML protocol would be heavyweight. It uses a single ServerAnchor without a client anchor, does not support breakpoint‑resume, but still offers fast and slow sync modes.

File‑Sync Protocol Handles large binary objects such as photos, attachments, and user avatars. It relies on a unique UUID generated after a successful sync to match files with business entities.

Architecture Design

The service is deployed in multiple independent units (clusters), each serving roughly 5 million users. Units are isolated for modular scaling, fault isolation, and easy capacity expansion. Three data‑center sites are connected through a custom Global Server Load Balancer (GSLB) that routes users to the nearest site based on IP or user ID, mitigating DNS hijacking and reducing latency.

Additional routing components provide self‑routing capabilities, mirroring GSLB functionality within the application layer. The architecture also includes extended GSLB that maps sub‑domains to specific data‑center sites, enabling fine‑grained traffic distribution.

Technical Challenges

Module Communication With many modules, the system relies on Zookeeper, Kafka, and other middleware to coordinate interactions.

Connection Management Long‑lived connections waste resources because ~80 % of the time the connection is idle; short‑lived connections reduce server load and improve QPS.

Security Data at rest is encrypted to prevent immediate reading if storage is compromised, and module isolation limits the blast radius of component failures.

High Availability Redundant units and cross‑site replication ensure service continuity; in case of a fiber cut, traffic is rerouted via GSLB to a backup site.

Storage & Routing Hot data is stored in relational databases (RDB) while cold data (e.g., recycle bin) uses HBase. User IDs are horizontally sharded across dozens of databases.

Performance Optimizations Batch inserts are replaced with map‑based loops to reduce transaction overhead; sync tasks are merged to lower network calls; Wi‑Fi‑only sync and non‑resident processes reduce power consumption.

Integration Guidelines New apps must follow a defined integration specification, which includes SDK‑API usage and API‑level contracts.

Future Directions

Meizu plans to expose a public SDK‑API and cloud‑extension services to allow third‑party developers to integrate with the sync platform without tightly coupling to the core codebase. An open‑day initiative encourages community contributions and broader adoption beyond Flyme.