4 Types of Feature Flags and When to Use Them

@ Technical Discussion

Introduction

Previously we explored: What Is Feature Flag and What Problem Does It Solve?, and after understanding the value of Feature Flags, today we’ll look deeper into the four types of Feature Flags and their practical uses. Flags with different purposes have distinct characteristics in lifecycle, dynamism, and management strategy.

Two dimensions of Feature Flags

Feature Flags can be classified along two dimensions: “lifespan” and “dynamism”.

  • Lifespan:
    • Short-term: usually for transitional purposes, such as feature releases or experiments.
    • Long-term: often becomes part of the product design.
  • Dynamism:
    • Low dynamism: values are typically fixed and rarely change during runtime.
    • High dynamism: values change frequently and may be decided in real time based on user, request, or environment.

The four quadrants map to different uses of Feature Flags:

                 High dynamic
                      ↑
                      │
      Experiment      │      Permissioning
      Flags           │      Flags
                      │
──────────────────────┼────────────────────→ Lifespan
                      │
      Release         │      Ops
      Flags           │      Flags
                      │
                      ↓
                  Low dynamic

The 4 quadrants of Feature Flags

Short-term × Low dynamism → Release Flags

Set a clear removal deadline; remove after the feature is fully released

In Trunk Based Development🔗 you use Feature Flags instead of branches to achieve the decoupling of code deployment and feature release, preserving development velocity by separating deployment from release.

  • Progressive rollout: deploy code but keep the feature off, then flip the switch when ready
  • Canary release: enable the new feature for a small subset of users first to observe stability
  • Fast rollback: if the new feature causes problems, turn off the flag immediately without redeploying
  • Decouple deployment and release: make code deployment and feature activation independent actions

Short-term × High dynamism → Experiment Flags

Run experiments to collect data for decision-making; after an experiment ends, converge based on the conclusions
  • A/B testing: compare different versions of UI, algorithms, or features to see which performs better
  • User cohort experiments: dynamically test different strategies on different user groups

Long-term × High dynamism → Permissioning Flags

Design a clear permission model; avoid mixing with experiments

User permissions, subscription status, and attributes change frequently and require immediate response:

  • Experiment access: early adopter programs, internal staff testing features
  • Geolocation restrictions: some features available only in certain countries/regions, or required by local regulations
  • Different cohorts: admin vs regular users, free vs paid features

Long-term × Low dynamism → Ops Flags

Reliability and observability
  • Defensive fallback: disable non-core features during traffic spikes, reduce frequency of resource-intensive operations, enable caching or simplified feature variants
  • Maintenance mode: switch to read-only during database maintenance, show maintenance pages during system upgrades, temporarily disable certain server endpoints
  • Special scenarios: enable extra monitoring or logging during specific periods

Further reading