Feature flags (also called feature toggles or feature switches) decouple code deployment from feature release, enabling teams to ship dark features and activate them independently for specific users, regions, or percentages of traffic. This pattern, championed by Martin Fowler and Pete Hodgson, eliminates long-lived feature branches and enables gradual rollout, A/B testing, and instant kill switches for defective features. Platforms like LaunchDarkly, Flagsmith, Unleash, and AWS AppConfig provide flag management with millisecond evaluation latency.

Key Points

  • Release toggles: the most common type — hide incomplete features from users while code ships to production; removed after full rollout.
  • Experiment toggles: A/B test two implementations against a control group — Google uses this for every significant UI/algorithm change.
  • Ops toggles: kill switches for expensive or risky features — disable in production without a code deploy during an incident.
  • Permission toggles: expose features to specific user segments (beta users, enterprise tier, internal employees) for gradual access control.
  • Gradual rollout: start at 1% → 10% → 50% → 100%, monitoring error rates and business metrics at each threshold.
  • Flag debt: unremoved flags accumulate as technical debt — enforce a TTL policy; archive flags after full rollout, maximum 30-day lifespan for release toggles.
  • Consistency: use a sticky bucketing algorithm (user ID hash) so a user always sees the same variant — prevents flickering experiences.
  • LaunchDarkly evaluates flags client-side with a streaming SDK — flag changes propagate globally in <200ms without redeployment.

Real-World Example

Facebook (Meta) deploys code to 100% of servers every day using feature flags called "Gatekeeper." A new feature might be live on servers for weeks before it is visible to any user. This enabled the News Feed algorithm change to roll out safely to 2.9 billion users over 3 months.