Why Meizu Adopted Multi‑Data‑Center Deployment and How It Works

After rapid growth and a sales boom in 2014‑2015, Meizu’s internet services expanded beyond the capacity of a single‑datacenter architecture, and the complex domestic network environment made a single site unreliable due to frequent fiber cuts and power outages. To satisfy both reliability and user‑proximity requirements, Meizu designed a multi‑datacenter deployment.

Technical Challenges

High network latency and limited bandwidth between datacenters; dedicated carrier lines are costly and not fully reliable.

Complex service dependency graphs.

Precise inter‑datacenter traffic scheduling.

Minimal changes to existing business logic.

Industry solutions such as Alibaba’s unit‑based isolation, Tencent’s SET, and Weibo’s cross‑datacenter design inspired Meizu’s approach.

Meizu’s Multi‑Datacenter Solution

Meizu classifies its services into two categories:

Read‑heavy, write‑light workloads (treated as read‑only).

Read‑write balanced workloads that can be partitioned by user.

Read‑Heavy Services

The App Store’s single‑datacenter architecture is shown below (image omitted). Three front‑ends—API, Developer Community, and Operations Backend—access the service.

API serves mobile clients, mainly reading leaderboard data from cache with minimal database writes (statistics, comments).

Developer Community handles app uploads and maintenance, with balanced read/write traffic.

Operations Backend supports internal staff for app publishing, involving more writes.

Availability requirements are tiered: the API demands the highest uptime, while the community and backend have slightly lower requirements. Consequently, only the API is deployed across multiple datacenters.

The multi‑datacenter App Store architecture replicates MySQL data from the East‑China core datacenter to other sites, while read traffic is served from Redis caches synchronized via scheduled jobs. Writes remain single‑point to the core datacenter, either queued in a message queue (allowing eventual consistency) or performed synchronously with immediate failure handling and possible degradation.

Inter‑datacenter traffic is directed using Global Server Load Balancing (GSLB), described later.

Read‑Write Balanced Services

These services can be partitioned by user, with low cross‑user coupling. An example is the synchronization service that backs up contacts, messages, settings, etc., to the cloud, enabling data recovery after device loss or re‑flashing.

The single‑datacenter sync architecture (image omitted) shows separate API endpoints for mobile and web clients. Requests are routed to backend services that store data in sharded databases based on user routing information.

In the multi‑datacenter design, each user’s data is replicated to a local Unit (a self‑contained service instance) and a remote backup Unit. Units are deployed in multiple datacenters, allowing failover by activating the backup Unit when a site fails.

Clients access services through GSLB, which first determines the user’s data location and then directs the request to the appropriate datacenter. Web traffic, however, cannot use GSLB directly, posing a challenge addressed later.

Precise Traffic Scheduling

Simple traffic distribution can rely on intelligent DNS (smart DNS) that resolves user IPs to ISP and region, directing them to the nearest datacenter. This approach suffers from DNS hijacking, user‑specified DNS servers (e.g., 8.8.8.8) returning unrelated IPs, inability to route based on user identity, and lack of server‑health awareness.

To overcome these limits, Meizu adopts GSLB (or HttpDNS) which allows clients to include user identifiers (IP, UID, etc.) in requests, enabling precise routing and avoiding DNS hijacking. Benefits include:

* Precise routing based on IP/UID.
* Protection against DNS hijacking.
* Correct routing even when users set custom DNS.

All Meizu client traffic—App Store, sync APIs, etc.—now passes through GSLB.

However, GSLB works only for HTTP/HTTPS client requests, not for generic web browsers. To support browser traffic, Meizu proposes a hybrid GSLB + smart DNS solution: the client first resolves a DNS name, contacts a GSLB service to discover the correct datacenter, and is redirected if necessary. This may cause domain changes in the browser and does not fully eliminate domain‑level hijacking.

Overall, Meizu’s multi‑datacenter strategy combines selective service replication, message‑queue‑based write buffering, Redis caching, and GSLB‑driven traffic steering to achieve higher reliability and better user proximity while acknowledging remaining limitations for pure web traffic.