Feature Flagging

Feature flags evaluate conditional logic at runtime, not build time. This decouples deployment from release, allowing code to be deployed to production in a dormant state and activated later without a redeployment. The flag's state is resolved per-request by querying a rules engine, enabling instantaneous kill switches and gradual rollouts.

Modern flags go beyond simple boolean checks. They support complex targeting based on user context:

• User Identity: Email domain, user ID, or account tier.
• Geography: Country, region, or specific IP ranges.
• Attributes: Custom properties like beta_opt_in = true or subscription_level = 'pro'.
• Percentage-Based: Randomized assignment to a cohort for canary releases and A/B tests.

A flag's lifecycle must be managed to prevent technical debt. Flag debt occurs when obsolete toggles clutter the codebase. A mature system enforces:

• Time-to-Live (TTL): Flags automatically expire after a set duration.
• Ownership Metadata: Each flag is assigned to a specific team with a contact email.
• Removal Automation: Automated pull requests strip out fully rolled-out flags.

To prevent user confusion and inconsistent state, a single user must receive the same flag variation across all services and sessions. This requires a deterministic hashing algorithm applied to a unique user identifier. The evaluation must be idempotent, ensuring that a user in the 'treatment' group always sees the new feature, even across different microservices.

A source-control branching model where developers collaborate on code in a single branch called trunk, integrating changes frequently. Feature flags are a critical enabler, allowing incomplete features to be merged into the trunk without being visible to users. This prevents merge hell and enables continuous integration by decoupling deployment from release.

A deployment strategy that reduces the risk of introducing a new software version by rolling it out to a small subset of users before a full launch. A feature flag targeting a 5% user cohort acts as the canary mechanism. If error rates spike, the flag is toggled off instantly, limiting the blast radius without a rollback.

A randomized experimentation method comparing two versions of a feature to determine which performs better against a specific metric. Feature flags serve as the randomization engine, assigning users to control and treatment groups. This allows product teams to make data-driven decisions based on statistical significance rather than intuition.

A specific type of feature flag designed as an operational safety mechanism to immediately disable a system component under duress. Unlike a standard toggle, a kill switch is engineered for extreme low latency and may bypass complex targeting rules. It is used to shut down non-critical features during a traffic surge or to disable a vulnerable library during a zero-day exploit.

A modern software release philosophy that combines continuous delivery with granular control over the user experience. It moves beyond binary on/off states to sophisticated rollout plans:

• Start with internal employees
• Expand to 10% of free users
• Ramp to 50% of paid users
• Complete the universal launch Feature flags are the core mechanism orchestrating this phased exposure.

A long-lived flag used to control infrastructure behavior rather than a temporary product feature. Examples include toggling between a primary and secondary database, enabling a new caching layer, or adjusting a background job's batch size. These flags are often managed by SRE teams and may persist for years, requiring strict governance to avoid technical debt.