Mobile Development 5 min read

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:

mobile developmentsoftware architectureConfiguration ManagementFacebookmobile 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

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.