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.
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:
Continuous Delivery 2.0
Tech and case studies on organizational management, team management, and engineering efficiency
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.