In brief: A feature flag is a temporary operational control; without ownership and expiry it becomes an undocumented second codebase.
The problem
Boolean flags multiply into untested combinations, targeting differs across services, stale SDK caches produce inconsistent behaviour and emergency kill switches fail because nobody exercised them.
Why the simple answer is not enough
Deployment answers whether code exists; release answers who may use it. Separating them enables canaries and instant disablement without another build.
Flags used as entitlements or security controls need stronger consistency and audit than a short-lived UI rollout flag.
System flow
versioned flag policy→SDK snapshot
local deterministic evaluation→Application
flagged decision→Telemetry
exposure and outcome
Architecture decisions
Type flags by purpose
Release flags expire quickly; experiments require exposure events; operational kill switches need drills; entitlements belong to policy management.
Evaluate close to the request
Distribute signed snapshots and evaluate locally to avoid making a central flag service a request-path dependency.
Record exposure, not only configuration
Capture flag key, version and variant when the user actually reaches the feature, with privacy-aware sampling.
Going deeper
Flagged changes still need compatibility
Code, schema and events must support both variants during rollout. A flag cannot undo a destructive migration.
Combinations must be bounded
Define allowed dependencies and mutual exclusion. Pairwise tests help, but the best defence is fewer simultaneous flags in one journey.
Implementation path
- Classify release, experiment, permission and operational flags separately.
- Give every flag owner, creation date, expiry and safe default.
- Roll out by deterministic cohort and compare SLO plus business outcomes.
Technical example: Typed flag declaration
flag checkout_v2 {
type: RELEASE
owner: commerce-team
expires: 2026-08-31
default: CONTROL
targeting: stableHash(tenantId)
}A schema validator should reject missing owners, invalid defaults and expiry beyond the allowed lifetime.
Failure modes to design for
- Two services evaluate different flag versions in one workflow.
- A database migration is irreversible while the UI flag is rolled back.
- An experiment counts assigned users who never saw the feature.
What to observe
| Signal | Why it matters |
|---|---|
| Evaluation and exposure by version | Shows who actually ran which code path. |
| SLO and outcome by variant | Supports safe rollout and experiment decisions. |
| Flag age and expired count | Measures operational debt. |
How to validate the design
- Replay the same subjects across SDKs and compare variants.
- Disconnect the flag control plane and verify local safe defaults.
- Exercise every kill switch under representative load.
Safe rollout plan
Introduce a typed registry and inventory existing flags. Add exposure telemetry, then CI expiry enforcement in warning mode before blocking. Migrate high-risk kill switches first and schedule recurring cleanup.
Production checklist
- The same subject receives the same variant across devices and services.
- Flag evaluation failure has a documented fail-open or fail-closed default.
- Expired flags fail CI until removed or explicitly renewed.
Takeaway
Flags improve release safety only when their decisions are observable and their lifecycle ends.