What is the Feature Flags pattern?
A feature flag is a named switch that code checks at runtime: if the flag is on for this user, take the new path. Flags are managed in a shared service with targeting rules, such as internal users only, ten percent of customers or one country. Release flags are short-lived and removed once a feature is fully live. Operational flags, such as a kill switch for an expensive feature, may stay.
What problem does the Feature Flags pattern solve?
With many services and clients releasing independently, a feature often needs changes in several places that cannot ship at exactly the same moment. Flags let each part deploy whenever it is ready, with the feature switched off, and release it when everything is in place. They also make rollback a switch rather than a redeploy.
How do you implement the Feature Flags pattern?
- Use a shared flag service with SDKs for every stack, including web and mobile, so one flag works across layers.
- Evaluate flags with a stable user or account key, so a user sees the same thing on every request.
- Default to the safe behaviour when the flag service is unreachable.
- Give every release flag an owner and an expiry date, and remove the flag and the old code path once the feature is fully on.
- Record flag changes in an audit log and show them next to deployments on dashboards.
When should you use it?
- A feature spans several services or clients that deploy independently.
- You want to release gradually, run experiments or keep a quick off switch for risky features.
When should you avoid it?
- The change is small and safe to release with the deploy. A flag adds a code path for nothing.
- The switch is really long-lived configuration. Use externalized configuration instead.
What do you gain?
- Deploy and release become separate steps
- Gradual rollouts and fast rollback
- Features spanning several teams can ship in any order
What does it cost?
- Two code paths to test while the flag exists
- Old flags pile up as technical debt
- Flag combinations can behave in unexpected ways
Who usually owns the Feature Flags pattern?
Platform and product teams. A platform team provides the building blocks, such as a library, a managed service or a standard, and each product team applies them in its own code and configuration. See how teams map to layers and patterns.
What are common mistakes with the Feature Flags pattern?
- Flags that are never removed, leaving hundreds of dead branches nobody dares delete.
- Evaluating a flag differently in two services, so one request half uses the new behaviour.
- A flag service outage that turns every feature off, or on, at once.
Feature Flags in practice
By 2016, Facebook's model of a release branch with daily pushes of cherry-picked changes was reaching its limit.
Facebook moved facebook.com to pushing from master every few hours, reaching all production web servers in April 2017. New changes are kept behind its Gatekeeper system, so code ships separately from features, and a problem can be fixed by switching the gatekeeper off instead of reverting. Pushes go to employees first, then 2% of production, then everyone.
Source: Rapid release at massive scale (Engineering at Meta, 2017)
Example decision record
- Context
- Features that span several independently released services and clients are delayed by coordinated release dates.
- Decision
- Ship cross-team features behind a shared feature flag and release them gradually once every part is deployed.
- Consequences
- Teams deploy on their own schedule and rollback is a switch.
- Every release flag needs an owner and an expiry date.
Test yourself on Feature Flags
A new checkout flow needs changes in the web app, the mobile app, the checkout BFF and the payments service, owned by four teams with different release schedules. How can it go live safely?
3 questions involve this pattern. Practice all of them →
Saved in this browser only. See your progress →