DevOps
Feature Flags
Runtime switches that turn code paths on or off without redeploying — decoupling deployment from release. They enable trunk-based development, gradual rollouts, instant kill switches and A/B tests. Left unmanaged they rot into a combinatorial maze; every flag needs an owner and a removal date.
Purpose
A feature flag is an if whose condition lives outside the code — a config value, a percentage, a user segment — so shipping code and exposing behaviour become separate decisions. Deploy the half-finished feature dark; turn it on for staff, then 1%, then everyone; turn it off in seconds when it misbehaves. The deploy stops being the moment of risk.
When to Use It
Trunk-based development (merge incomplete work safely behind a flag instead of long-lived branches), canary-style percentage rollouts, kill switches on risky dependencies, A/B experiments, and entitlement gating — beta programs, plan tiers. The kill switch alone justifies the pattern: flipping a flag is minutes faster than the fastest rollback.
Trade-offs
Every flag doubles the theoretical state space, and nobody tests all combinations — so stale flags are latent bugs (Knight Capital's $460M loss involved a repurposed dead flag). The flag service becomes a dependency with its own failure modes, and evaluating sensitive flags client-side leaks unreleased features to anyone reading the bundle.
Implementation
Evaluate server-side where it matters, with a hard-coded safe default if the flag service is unreachable. Keep rollout state (percentage, segments) in the flag system, not the code. And treat flags as borrowed complexity: named owner, expiry date, and a recurring chore that deletes flags at 0% or 100% — the flag's last commit should be its removal.