Feature Flag
Definition
Technique for enabling or disabling application features without deploying new code, allowing for safer testing and gradual feature rollouts.
Use Cases
- Netflix: Gradual rollout and quick rollback of UI and backend behavior changes across a large user base — Netflix has publicly discussed using runtime configuration and controlled rollouts (often described as feature toggles) to enable/disable functionality and to perform canary-style releases without redeploying every service. (Reduced deployment risk by limiting blast radius, faster experimentation, and the ability to disable problematic changes quickly.)
- GitHub: Progressive delivery of new product features to subsets of users and internal dogfooding before broad release — GitHub has publicly referenced using feature flags/feature toggles to control exposure of new functionality, allowing staged rollouts and safe iteration while keeping code deployed. (Safer releases, improved ability to test in production with limited audiences, and faster iteration cycles.)
- Shopify: Controlled release of changes during high-traffic events (e.g., major sales periods) and experimentation on storefront/admin features — Shopify engineering has discussed using feature flags to gate functionality, enabling gradual rollout and quick disablement when issues arise, often paired with monitoring and incident response practices. (Lower operational risk during peak traffic, faster mitigation when regressions occur, and more reliable experimentation.)
Frequently Asked Questions
- What's the difference between a feature flag and a canary release?
- A feature flag is a switch in your application that turns a feature on or off at runtime (often per user, per region, or per percentage). A canary release is a deployment strategy where you ship a new version to a small portion of traffic first. They’re often used together: you can deploy code everywhere, then use a feature flag to expose it to a small audience and expand gradually.
- When should I use feature flags?
- Use feature flags when you want safer releases and more control over who sees a change. Common cases include gradual rollouts, A/B testing, separating deployment from release (deploy now, enable later), quickly disabling a problematic feature without a redeploy, and running experiments for specific user segments. Avoid using them as permanent branching logic—plan to remove flags after the rollout is complete.
- How much do feature flags cost?
- Cost depends on how you implement them. Third-party feature-flag platforms typically charge by seats, monthly active users, requests/evaluations, environments, and advanced capabilities (experimentation, approvals, audit logs). A self-managed approach can be low direct cost but requires engineering time and infrastructure (a config store or database, caching, high availability, monitoring, and security). Also consider indirect costs: operational overhead, performance impact of flag checks, and the need to clean up old flags.
Category: software
Difficulty: intermediate
See Also