Feature Flags

Deploying code to production without actually turning it on.

The idea

Historically, when you deployed code, all users saw the new feature instantly. If it crashed, you had to scramble to "roll back" the entire deployment, which takes time. Feature Flags (or Feature Toggles) decouple deploying from releasing. You wrap your new code in an if statement connected to an external dashboard. You deploy the code to production, but keep the flag "Off". No one sees it. Then, you turn the flag "On" for just 1% of users, or just internal employees. If something breaks, you click "Off" on the dashboard, and the feature vanishes instantly without touching the code.

How it works (The Toggle Service)

A Feature Flag is just a boolean check evaluated at runtime. The Application asks a centralized Toggle Service (like LaunchDarkly or an internal Redis cache) if a specific user should see the feature.

// 1. App asks the Toggle Service
const isDarkModeEnabled = await flags.check('dark_mode_beta', user.id);

if (isDarkModeEnabled) {
    // 2. Only users with the flag see the experimental code
    renderDarkMode();
} else {
    // 3. Everyone else sees the safe, existing code
    renderLightMode();
}

Cost

Feature Flags create Technical Debt. Every flag creates two branching paths in your code that must be tested. If you leave 50 old feature flags in your codebase long after they were fully rolled out, your code becomes an unreadable mess of nested if statements. You must have a disciplined process to delete old flags from the code once they reach 100% rollout.

Watch out for

• Latency: If your web server has to make an HTTP request to LaunchDarkly for every single user request, you will add 50ms of latency to your app. Feature Flag SDKs usually solve this by maintaining a long-polling connection and syncing the rule-set to local memory, so evaluating flags.check() takes 0.01ms.