Feature Flag

A feature flag (also called a feature toggle) is a named boolean or value that your code reads before deciding which path to run. In the simplest form it is an if statement: if the flag new_checkout is on, run the new checkout code, otherwise run the old one. The flag's value lives outside the compiled code, in a config file, a database row, or a remote service, so you can change it without rebuilding or redeploying.

The point is to break the link between deploying code and releasing a feature. You can merge unfinished work into the main branch and deploy it to production every day, kept dark behind a flag set to off. The day the feature is ready, someone flips one value and it goes live. If it breaks, you flip it back in seconds instead of waiting for a rollback deploy that might take ten or twenty minutes.

Flags come in a few flavors. Release flags hide work in progress. Experiment flags split traffic for A/B tests. Ops flags act as kill switches for expensive or risky subsystems. Permission flags gate features to paid plans or specific accounts. They look the same in code but have very different lifetimes.

At its core a flag system has two parts: an evaluation point in your application and a source of truth for the flag's value. When your code asks is new_checkout enabled for this user, the flag SDK evaluates a set of rules against the current context (user id, plan, country, an internal flag) and returns true or false.

Percentage rollouts work by hashing a stable key, usually the user id, together with the flag name, mapping the hash to a bucket from 0 to 99, and turning the flag on if the bucket falls under the rollout percentage. Because the hash is deterministic, the same user always lands in the same bucket, so a user who got the new feature at 5% keeps it when you raise the rollout to 20%. That stickiness is what makes A/B tests valid.

Production systems do not hit a remote server on every check. SDKs from LaunchDarkly, Unleash, or Flagsmith stream the full ruleset to each app instance and cache it in memory, so an evaluation is a local microsecond-level lookup. Changes are pushed over a streaming connection or polled every few seconds, which is why a flip feels near instant across a fleet.

Reach for flags when you want trunk-based development with frequent deploys, when you need to roll a risky change out gradually and watch error rates, when you want a kill switch for a dependency that might fail under load, or when you run experiments. They pair naturally with canary releases and let product managers control timing without an engineer on standby.

The cost is complexity. Every flag is a branch in your code, so two flags create four code paths and your real test matrix grows fast. Flags that never get cleaned up rot into permanent dead branches; teams that do not enforce removal end up with hundreds of stale toggles nobody understands. Knight Capital's 2012 trading loss of about 440 million dollars came partly from reusing an old flag that re-activated dormant code on one of eight servers.

Treat flags as short-lived by default. Give each release flag an owner and an expiry, track them in a dashboard, and delete both the flag and the losing code path once a feature is fully shipped. Long-lived ops and permission flags are fine to keep, but label them so nobody mistakes them for cleanup debt.