Feature Flags

A deployment puts code into an environment. A release exposes behavior to users. Feature flags separate those events.

You can deploy new and old behavior together, then choose which behavior runs. That choice happens at runtime. It can apply to everyone, a named group, a percentage, or one evaluation context.

This separation gives you a smaller control surface than another deployment. It does not make the change safe by itself. You still need tests, observable results, an owner, and a cleanup decision.

The core mental model

A feature flag is a named decision inside deployed software.

flag key + default value + evaluation context
                    |
                    v
               evaluation
                    |
                    v
          value or named variant
                    |
                    v
              code behavior

The flag key identifies the decision. The default value protects the application when evaluation fails. The evaluation context describes the subject, such as a user, account, service, or request.

Rules use that context to select a value. A Boolean value chooses between enabled and disabled behavior. A string, number, or structured value can select a named variant or configuration.

The code that asks for a value is the evaluation point. Keep it close to the boundary that chooses behavior. Keep the rule that selects an audience in the flag system. This separates the decision point from decision logic.

The control plane and data plane