Feature flags and progressive delivery

Introduction

Feature flags (or feature toggles) are conditional statements embedded in application code. A central configuration service evaluates these statements at runtime. If the flag evaluates to true, the application executes the new code path. If false, it executes the existing code path.

This decouples deployment from release. You deploy the code to production early and often, but only release the feature to users when the business is ready. Progressive delivery builds on this by tying flag evaluation to specific conditions, such as user IDs or geographic regions.

Mental Model

Think of a feature flag as a remote-controlled light switch. The electrician installs the wiring and the bulb (deployment). The bulb remains off. Later, someone flips the switch (release) from a control panel, illuminating the room. If the bulb flickers dangerously, they flip the switch back off (rollback) instantly.

Operational Pattern

The application initializes an SDK provided by a feature management service. When the code reaches a flagged feature, it queries the SDK. The SDK evaluates the user context against a set of rules downloaded from the central service.

Rules evaluate deterministically. If a rule specifies that 20 percent of users see a feature, the SDK hashes the user ID to ensure the same user consistently receives the same flag state.

If a severe error occurs, an operator toggles the flag off in the central dashboard. Within seconds, the SDKs receive the updated rule and disable the feature. This acts as an instant kill switch, bypassing the deployment pipeline entirely.

Failure Modes

Flag debt accumulates rapidly. A team creates a flag, rolls out the feature, and forgets to remove the conditional logic. Over time, the codebase fills with dead code paths and untestable permutations of flag states.

Flag evaluation adds latency. If the SDK requires a synchronous network call to the central service to evaluate a flag, it blocks the application thread.

Inconsistent flag states break transactions. If a flag state changes midway through a multi-step user journey, the application might process the first step with the old logic and the second step with the new logic, corrupting data.

Security

Feature flags control critical application behavior. Treat the flag management dashboard as a highly sensitive system. Require multi-factor authentication and role-based access control to prevent unauthorized toggling.

Do not send restricted data in the user context payload. The SDK sends user context (e.g., email, organization ID) to the evaluation engine. This context must not include passwords, session tokens, or unencrypted personally identifiable information.

Assume flags can fail open. A network partition might prevent the SDK from fetching rules. Define a safe default fallback value for every flag in the application code.

Operational Guidance

Establish a flag lifecycle. Treat a feature flag as a temporary construct. Create a ticket to remove the flag at the exact same time you create the ticket to implement it.

Use local evaluation. The SDK should download the rule definitions asynchronously and cache them in memory. Flag evaluations should occur locally against this cache to avoid blocking network calls.

Maintain session consistency. Cache flag decisions for the duration of a user session. A user’s experience must not change randomly while they interact with the application.

Diagnostics

Monitor SDK initialization time. A slow initialization delays application startup.

Track flag evaluation counts. If a flag evaluates zero times over a week, it indicates dead code that requires removal.

Correlate flag changes with error metrics. Annotate monitoring dashboards with flag toggle events. This helps operators quickly identify the root cause of a sudden spike in errors.

Related topics

• Canary releases

Sources & further reading

• Feature Toggles - Martin Fowler, 2017