Feature Flags — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about feature flags.
Feature flags were pioneered by Flickr in 2009¶
Flickr's engineering team, led by John Allspaw, pioneered the use of feature flags (they called them "feature flippers") around 2009 to enable continuous deployment. Their approach allowed them to deploy code to production with new features hidden behind flags, then enable features independently of deployments.
Facebook's Gatekeeper controlled features for 2 billion users¶
Facebook built an internal feature flag system called Gatekeeper that controlled feature rollouts to over 2 billion users. Gatekeeper could target features by user ID, geographic location, device type, and dozens of other attributes. It handled millions of flag evaluations per second with sub-millisecond latency.
"Dark launching" was coined by Facebook engineers¶
The term "dark launching" — deploying code to production that runs but isn't visible to users — was coined by Facebook engineers around 2011. They would deploy new features to all servers, execute the code paths under production load, but hide the UI changes behind feature flags. This validated performance before any user saw the feature.
LaunchDarkly was valued at $3 billion in 2022¶
LaunchDarkly, the leading feature flag platform, was valued at $3 billion in its 2022 Series E funding round. The company's success demonstrated that feature flags had evolved from a simple boolean toggle into a sophisticated platform for progressive delivery, experimentation, and release management.
Google Chrome uses feature flags for every new feature¶
Google Chrome has an internal feature flag system with hundreds of active flags. Users can access many of these via chrome://flags. Every new Chrome feature goes through a multi-stage rollout controlled by flags: Canary channel, Dev channel, Beta channel, then Stable — with the ability to kill any feature instantly.
Feature flag debt is a real and growing problem¶
Martin Fowler identified "feature flag debt" — the accumulation of stale, unused flags — as a significant code quality issue. A 2021 study found that the average feature-flagged codebase had 40% more conditional branches than equivalent unflagged code, and 25% of flags had been in the code for over a year past their intended removal date.
Kill switches are feature flags in reverse¶
The most critical feature flags aren't for launching features — they're for turning things off. "Kill switches" allow teams to instantly disable a feature in production if it causes problems. Amazon, Netflix, and Google all maintain hundreds of kill switches that can shed non-essential functionality during cascading failures to preserve core services.
OpenFeature standardizes feature flag APIs across vendors¶
The OpenFeature project, accepted by the CNCF in 2023, provides a vendor-neutral API for feature flag evaluation. Before OpenFeature, switching feature flag providers (e.g., from LaunchDarkly to Unleash) required rewriting flag evaluation code throughout the application. OpenFeature provides a standard SDK that works with any backend.
Feature flags enable "testing in production" at scale¶
Before feature flags, "testing in production" was considered reckless. Feature flags made it a legitimate strategy: deploy to production, enable for 1% of users, monitor for errors, gradually increase. This approach catches issues that staging environments miss because staging never perfectly replicates production's scale, data, and traffic patterns.
The "flag explosion" at Knight Capital cost $440 million¶
In August 2012, Knight Capital Group deployed code that accidentally reactivated a dormant feature flag controlling an old trading algorithm. The algorithm ran uncontrolled for 45 minutes, making erroneous trades that cost $440 million and nearly bankrupted the company. It remains the most expensive feature flag incident in history.