Feature Flags vs Configuration: Different Lifetimes, Different Risks
Flags control code paths and are meant to be removed; configuration tunes behaviour and persists. Mixing them creates permanent toggles nobody dares delete.
Definition
A feature flag is a runtime switch that selects between code paths, usually for rollout, experimentation, or kill switches, and it should be short-lived. Configuration is data that parameterizes a single code path, such as timeouts, limits, and endpoints, and it is expected to live as long as the system.
Context and scope
Both often arrive through the same config service as key-value pairs, so teams store them together and lose track of which entries can safely be deleted.
Common misconceptions
- A flag is just a config key — flags branch logic, configuration tunes it
- Flags are free to keep — each stale flag doubles the states you must test
- Config changes are always safe — a bad limit can take down a service as surely as a bad deploy
Anti-patterns
- Using long-lived flags as a substitute for proper configuration
- Storing secrets in the same store as flags
- Removing a flag and its dead branch in separate releases
Related concepts
Authoritative source
One store, two kinds of data
Flags and configuration often arrive through the same service, as key-value pairs in the same bucket, reviewed by the same people. The similarity is superficial. A flag selects between code paths at runtime; a configuration value parameterizes one code path. They differ in ownership, lifetime, and what happens when they are wrong.
Lifetimes
Configuration is expected to live as long as the system: timeouts, pool sizes, endpoints, limits. A flag is expected to be temporary: it exists to decouple deploy from release, to run an experiment, or to provide a kill switch. The target state for a rollout flag is deletion, and the pull request that removes it is part of the feature, not cleanup. Compared to a configuration change, which must remain valid for years, a flag has an expiry date from the day it is created.
What merging them breaks
When flags and configuration share a namespace, nobody knows which keys are safe to delete. Stale flags accumulate, each one doubling the number of states to test. Config keys that look like flags stay in place for years, and a temporary toggle quietly becomes an undocumented part of the contract.
A useful taxonomy
Release flags gate unfinished features and should be short-lived. Experiment flags split traffic for measurement and belong to the experiment owner. Ops flags act as kill switches and must be exercised regularly. Permission flags encode entitlement and are long-lived by design, which is why they belong in data models rather than in toggles.
Keeping them apart
For example, keep flags in a flag service with an owner, an expiry date, and an evaluation audit trail, while configuration lives with the deployment and is validated by a schema. Review flags in a recurring report sorted by age, and compare the active flag count against the number of services; a rising ratio predicts a testing problem before it shows up.