deploymentestablished · low operational burden

Feature Flag (Feature Toggle)

Also known as: feature-toggle, feature-flag, launchdarkly, split-io

Intent

Decouple deployment from release. Enable/disable features at runtime without code deploy.

Problem

Long-lived feature branches cause merge hell. Big bang releases are risky. Need to test in prod with real users safely.

Forces

•Deploy frequently (daily), release selectively
•Test in production with real traffic/users
•Instant rollback without deploy (kill switch)
•Target segments: internal, beta, percentage, geography

Solution

✓ When to Use

•Continuous deployment (deploy ≠ release)
•A/B testing, gradual rollout
•Kill switches for risky dependencies
•Premium features, entitlements

✗ When Not to Use

•Simple deployments (no branching needed)
•Flags that live forever (tech debt)
•Client-side only for security-sensitive flags

Pros

+Deploy daily, release when ready
+Instant rollback: flip flag
+Real-user testing before full launch
+Segment targeting: internal, beta, geo, %

Cons

−Flag debt: forgotten flags, nested conditionals
−Testing complexity: 2^N flag combinations
−Runtime overhead: flag evaluation on hot paths
−Security: client-side flags exposed

Cost Profile

Infrastructure

Low (Redis) to Medium (SaaS)

Operational

Medium — flag hygiene, cleanup process

Cognitive

Low — simple concept

Failure Modes

Flag evaluation failure → default (OFF) or crash
Stale flag config → wrong behavior
Flag explosion: 100s of flags, no cleanup
Nested flags: combinatorial testing impossible
Client-side flag leak: unreleased feature exposed

Real-World Examples

Alternatives

branch-based
canary-deployment
blue-green
dark-launch

Related Patterns

canary-deployment
dark-launch
kill-switch
ab-testing

Competency Domains

deploymentreliability opseconomics evolutiondistribution communication