Introduction
Most modern software runs multiple versions of the application to conduct experiments (e.g., A/B testing) or to deploy new versions safely (e.g., canary, blue-green deployments). To support this, feature flags are commonly used to toggle different functionality at runtime. Developers may add feature flags to introduce a new feature and progressively roll it out in production. Alternatively, feature flags may introduce different business or behavior logic per some external variable for experimentation or data collection.
While feature flags are a great tool for minimizing risk in validating new features and modifying behavior without disruptive deployments, it also adds complexity in debugging when the number of feature flags grows to be large. For large applications, it’s not uncommon to see multiple feature flags per service. In fact, it was reported that Facebook had over 60 different versions of the navigation bar at one time. Coupling that number with all the various microservices it communicates with, the combination of possible states grows exponentially large. So at scale, feature flags may be managed by a feature management platform like LaunchDarkly or AWS AppConfig.