Feature Flag

Feature flags (also called feature toggles) let you deploy code to production but control who sees it. Instead of releasing features to everyone at once, you can: - Roll out to 5% of users, then 20%, then 100% (gradual rollout) - Show feature to internal team first (dogfooding) - A/B test different versions (feature A vs feature B) - Kill switch bad features instantly without redeploying - Release features on your schedule, not deployment schedule **How feature flags work:** You wrap new code in an if statement that checks a flag. If flag is true, show new feature. If false, show old behavior. Example: `if (featureFlags.newCheckout) { showNewCheckout() } else { showOldCheckout() }` Flags are controlled by a config file or feature flag service (LaunchDarkly, Split, Unleash). You can toggle flags remotely without redeploying. **Why feature flags matter:** Decouple deployment from release. You can deploy risky code to production without users seeing it. Test in production safely. Turn it on for your team first, then beta users, then everyone. Faster iteration. No waiting for release cycles. Ship code daily, enable features when ready. Risk mitigation. If a feature breaks production, turn it off instantly. No rollback, no redeploy—just flip the flag. A/B testing. Show variant A to 50% of users, variant B to the other 50%, measure which performs better. **Types of feature flags:** - Release flags: Control gradual rollout of new features - Experiment flags: A/B tests, temporary flags deleted after test - Ops flags: Kill switches for performance-heavy features - Permission flags: Control access per user or account (enterprise features, beta access) **Best practices:** - Clean up old flags. Every flag is technical debt. Once feature is fully rolled out, remove the flag and the old code. - Name flags clearly (e.g., 'new_checkout_v2', 'dark_mode_enabled') - Monitor flag state in logs and analytics - Document what each flag does and who owns it - Don't nest flags too deeply (flags within flags = complexity nightmare) **When to use feature flags:** - Big rewrites or risky features (payment flow, auth system) - A/B testing product changes - Beta testing with select users - Per-customer features (enterprise tier gets X, free tier doesn't) - Ops kill switches for performance-heavy features **When NOT to use feature flags:** - Every single feature (too much complexity) - Simple bug fixes (just deploy the fix) - Internal-only tools that don't need gradual rollout Feature flags are powerful but add complexity. Use them strategically, not everywhere.

Facebook uses feature flags for every release—they deploy code constantly but control who sees features via flags. Stripe uses flags to test payment changes with 1% of traffic before full rollout. GitLab open-sources their feature flag system.