Feature Flag: How It Works, Types of Flags, and Management Principles
Feature Flag is a development technique where application functionality is enabled or disabled through conditional switches at runtime, without deploying new code. Instead of the traditional "commit — deploy" approach, feature flags allow separating the moment of deployment from the moment of feature enablement. According to LaunchDarkly (2024), teams using feature flags reduce feature rollout time by 40%. Feature flags have become an essential element of CI/CD for modern mobile and web applications.
Key Takeaways
- Feature Flag — a conditional switch that controls feature availability at runtime
- Four types of flags: release, experiment, ops, and permission toggles with different goals and lifecycles
- Flag management requires a storage system, configuration UI, and usage monitoring
- Platforms LaunchDarkly, Unleash, and Split provide SDKs for all popular languages and platforms
- Technical debt from uncleaned flags — the main risk: stale flags need regular auditing and removal
What Is a Feature Flag
Feature Flag (feature toggle) is a mechanism that allows changing application behavior without modifying code. In its simplest form, it is a conditional statement that checks the flag value before executing new functionality. The flag can be stored in a configuration file, database, or external service and changed in real time. This approach gives teams the ability to commit unfinished code to the main branch without fear of it reaching users before completion.
Definition and Purpose
The main purpose of feature flags is separating deployment from release. Deployment is the process of placing code on a server or in an app store. Release is the moment when functionality becomes available to the user. Without feature flags, these events coincide: code goes to production — users see it. With feature flags, code can be deployed to production weeks before release, enabled for internal testing, or gradually rolled out to the audience. This is critical for trunk-based development and continuous delivery.
Simple Flag Example
Consider a basic feature flag implementation in a mobile Kotlin application. The flag is stored in Firebase Remote Config and loaded when the app starts. Depending on the flag value, either the old or the new profile screen is displayed. This implementation allows releasing a new profile version without publishing an App Store update — just change the value in the Firebase console.
kotlin
class ProfileFeature {
private val flags = FeatureFlagProvider()
private val profileFlag = FlagKey("new_profile_enabled")
fun getProfileScreen(): Screen {
return if (flags.isEnabled(profileFlag)) {
NewProfileScreen()
} else {
LegacyProfileScreen()
}
}
}
class FeatureFlagProvider {
fun isEnabled(key: FlagKey): Boolean {
val raw = Firebase.remoteConfig.getString(key.name)
return raw.toBoolean()
}
}Types of Feature Flags
Not all feature flags are the same. Martin Fowler's classification identifies four types of flags, differing in usage purpose, lifespan, and management requirements. Proper flag classification helps choose the right infrastructure and avoid common problems.
Release Toggles
Release toggles are the most common type of flags. They are used to hide unfinished functionality in production. A developer commits code to the main branch wrapped in a flag and gradually completes the feature. After completion and testing, the flag is enabled for all users. The lifecycle of such a flag ranges from a few days to two weeks. After full rollout, the flag is removed from the code. Release toggles are the foundation of trunk-based development.
Experiment and Ops Toggles
Experiment toggles work in conjunction with A/B testing. They do not simply turn functionality on or off but route users to one of the experimental groups. Such flags often support complex targeting rules (by region, OS version, subscription) and integration with analytics systems. Ops toggles are used for operational control — for example, disabling a heavy feature under high load or temporarily turning off a problematic module without immediate deployment. Ops toggles must be as fast and reliable as possible, as service stability depends on them.
| Type | Duration | Dynamic | Purpose |
|---|---|---|---|
| Release | Days-Weeks | Static | Hide unfinished code |
| Experiment | Days-Months | Dynamic | A/B testing and rollout |
| Ops | Hours-Days | Dynamic | Operational control |
| Permission | Months+ | Static | Access control |
Feature Flag Management
Feature flag management is a separate discipline that includes storage, configuration, monitoring, and auditing of flags. Without a management system, flags turn into uncontrollable technical debt that slows down development. Let`s look at key management aspects using a production system as an example.
Flag Lifecycle
Each feature flag goes through four stages: creation, usage, stabilization, and removal. At the creation stage, the flag key, type, and default value are defined. During usage, the team monitors who enabled the flag, for which audience, and for what purpose. After stabilization (functionality is fully ready and tested), the flag must be removed from the code. The removal process is automated through code review: CI checks that all flags enabled for 100% of users have a removal task.
Centralized Storage
Feature flags should be stored centrally, not scattered across configuration files of each service. Ideally — a dedicated service with a UI (LaunchDarkly, Unleash). A minimally acceptable option is a JSON config in a repository with code review for changes. A database for storing flags is less preferred as it requires a separate management interface. Each flag should have an owner (team or specific developer), a description, and a time-to-live (TTL). Regular stale flag auditing is a mandatory practice, automated via a CI task that checks flags unchanged for more than N days.
Feature Flag Tools
The market for feature flag management tools includes both commercial platforms with a full management cycle and open-source solutions for self-deployment. The choice of tool depends on team size, latency requirements, and compliance needs.
Commercial Platforms
LaunchDarkly is the market leader with SDKs for all popular languages and platforms (iOS, Android, Web, Backend). It supports multi-environment, rule-based targeting, A/B experiments, and automatic flag removal. Split is an alternative focused on enterprise features: role-based access, audit logs, and compliance (SOC2, HIPAA). ConfigCat is a lighter and more affordable solution suitable for small teams. All platforms provide SDKs with value caching and minimal impact on application latency.
Open-Source Solutions
Unleash is the most popular open-source solution with a UI, API, and SDKs for all major platforms. It supports activation strategies, custom contexts, and integration with Prometheus for monitoring. Flagsmith is an alternative with built-in A/B testing and environment management. Open-source solutions require infrastructure deployment and maintenance but give full control over data and have no licensing restrictions. For mobile applications, both solutions provide native SDKs with offline flag value caching.
Best Practices
Feature flags are a powerful tool, but without discipline they create technical debt and complicate code. Martin Fowler and LaunchDarkly engineers have formulated a set of practices that help maximize the benefits of feature flags without negative consequences. Let`s review key recommendations for production systems.
Avoiding Technical Debt
Every feature flag that was not removed after rollout completion becomes technical debt. A LaunchDarkly (2024) study showed that on average 30-40% of flags remain in code after they are no longer needed. Solution: implement the “one flag — one task” rule. When creating a flag, a removal task with a deadline is created in the task tracker. CI checks that no flags enabled at 100% exist for longer than 30 days. Code review should verify not only adding but also removing flags.
Testing with Flags
Feature flags create combinatorial complexity for testing: each flag doubles the number of possible application states. To manage this complexity, matrix tests that check all flag combinations and feature flag toggling integration tests are used. A step is added to the CI pipeline that runs tests with different flag value combinations. For critical flags (ops toggles), load tests are mandatory to verify that flag switching does not cause latency spikes or errors.
python
class FeatureFlagService:
def __init__(self, storage):
self.storage = storage
def is_enabled(self, flag_key, user_context):
flag = self.storage.get(flag_key)
if not flag:
return False
for rule in flag["rules"]:
if self._match_rule(rule, user_context):
return rule["value"]
return flag["default"]
def _match_rule(self, rule, context):
return (
rule["percentage"] > self._hash(context.user_id)
)Frequently Asked Questions
How is a feature flag different from a feature toggle?
The terms are often used interchangeably, but there is a nuance: feature flag usually refers to a more mature system with centralized management, UI, and SDKs, while feature toggle is a simple binary switch in code. Martin Fowler uses feature toggle as a general term, but in the industry, feature flag is more often associated with commercial platforms (LaunchDarkly, Split).
How do feature flags affect performance?
The performance impact is minimal with proper implementation. Best practices: cache flag values in memory with a 30-60 second TTL, avoid synchronous HTTP calls when checking a flag, use SDKs with local caching and background synchronization. According to LaunchDarkly, the p99 latency of their SDK is less than 5 ms, which is negligible for most applications.
When should you avoid using feature flags?
Feature flags are not recommended for changing business logic in critical financial operations where it is important to know exactly which code is running. Also avoid flags for security functions (authorization, encryption) — disabling such a flag creates a vulnerability. For infrastructure changes (database migration, new architecture migration), feature flags are useful but require particularly thorough testing.
How to test code with feature flags?
The main approach is matrix testing: running tests with all flag combinations. For CI/CD this can be too expensive (2^n combinations), so in practice, all flags are tested individually in both states (on/off), and only critical combinations are tested. Unit tests should mock the flag value. Integration tests check specific scenarios with known flag values. E2E tests cover the most likely combinations.
How to remove old feature flags?
The removal process: 1) ensure the flag is enabled at 100% for all users and is not used in experiment mode; 2) remove all conditional flag checks from the code, keeping only the "new" branch; 3) remove the flag definition from the management system; 4) update tests by removing mocks for the removed flag. It is recommended to automate this process through CI: flags unchanged for more than N days are marked as stale and require removal confirmation.
Summary
- Feature Flag — a conditional switch that separates the moment of deployment from the moment of feature release
- Four types of flags (release, experiment, ops, permission) have different purposes, lifespans, and requirements
- Flag management requires centralized storage, a configuration UI, and regular stale flag auditing
- Tools: LaunchDarkly and Split for enterprise, Unleash and Flagsmith for open-source projects
- Technical debt from uncleaned flags is the main risk; removal tasks are mandatory when creating each flag
- Testing with flags requires a matrix approach and mocking flag values in unit tests
- Performance is minimally affected when using caching and local SDKs
We will develop a mobile application turnkey
IT Sectr creates iOS and Android applications for startups and businesses since 2017. We will advise you and propose the best solution.
Read also