Facebook Configuration Management (Six): MobileConfig – Architecture and Practices

This article explains Facebook's MobileConfig system, detailing its architecture, challenges of mobile configuration management, pull‑based update mechanism, translation layer, and how it scales to billions of devices while reusing data‑center tools.

Continuous Delivery 2.0
Continuous Delivery 2.0
Continuous Delivery 2.0
Facebook Configuration Management (Six): MobileConfig – Architecture and Practices

This series translates and expands upon Facebook Research's "Holistic Configuration Management at Facebook" article, providing Chinese readers with the original material and additional conference insights.

MobileConfig Architecture

Mobile application configuration differs from data‑center services due to network limitations, diverse platforms (Android and iOS), and long‑lived legacy versions. MobileConfig addresses these challenges while maximizing reuse of existing data‑center configuration tools.

In the mobile client, each configuration is represented by a Context class. Applications retrieve configuration fields via getter methods, and the client library—implemented in C++—is shared across Android and iOS.

Because push notifications are unreliable, MobileConfig uses a pull‑based approach: the client polls the server (e.g., hourly), caches configurations locally, and sends hashes of the configuration schema and cached values to minimize bandwidth. Future versions may store per‑client hashes server‑side to avoid redundant data.

The server only sends changed configurations relevant to the client’s schema version, and occasionally pushes urgent updates (e.g., disabling a defective feature). This pull‑plus‑push model provides a simple and reliable solution.

To handle legacy mobile versions, MobileConfig separates abstraction from implementation via a translation layer that maps MobileConfig fields to backend configuration stores (e.g., Configerator). This mapping can be altered without changing client code.

For example, the VOIP echo experiment was initially mapped to a GateKeeper‑controlled experiment; after the experiment concluded, the parameter was remapped to a constant in Configerator. Over time, backend systems like GK and Configerator can be replaced simply by updating the translation layer.

To scale beyond one billion devices, the translation layer runs on many servers, distributing mappings stored in Configerator to all translation servers.

In summary, Facebook’s holistic configuration management relies on multiple specialized tools—GateKeeper, Configerator, MobileConfig, etc.—to manage the full lifecycle of configuration items rather than a single monolithic solution.

(Continued in future posts.)

Below is the GateKeeper cascade switch dependency diagram referenced in an earlier article:

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Mobile DevelopmentSoftware ArchitectureConfiguration Managementmobile config
Continuous Delivery 2.0
Written by

Continuous Delivery 2.0

Tech and case studies on organizational management, team management, and engineering efficiency

0 followers
Reader feedback

How this landed with the community

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.