5 exercises on feature flag management vocabulary.
0 / 5 completed
1 / 5
What is a kill switch in feature flag terminology?
Kill switch (ops toggle): a permanent feature flag designed for rapid response. Unlike release toggles (temporary, removed after graduation), kill switches live indefinitely. They protect system stability. Examples: disable a new payment integration if the third-party service degrades; disable a resource-intensive recommendation algorithm during peak load; switch ML model from v2 back to v1 if v2 shows quality degradation. Kill switch vs circuit breaker: circuit breaker triggers automatically on error thresholds; kill switch is manual. Both are essential resilience tools.
2 / 5
What is flag debt and how does it accumulate?
Flag debt: every flag in the codebase at 100% rollout is dead code waiting to be removed. Costs: Dead code paths: the false branch of a fully-enabled flag is never executed, never tested. Bugs can hide there. Cognitive overhead: every developer reading the code must parse "what is this flag, is it on, what happens if off?". Testing complexity: N flags = 2^N possible code paths. Evaluation failures: if the flag service is unreachable and defaults are wrong, production behavior may be unexpected. Prevention: assign an owner and removal date when creating the flag. Create the removal ticket in the same sprint as the 100% rollout. Treat flag removal as a maintenance task with positive code health ROI.
3 / 5
What is sticky assignment in A/B testing with feature flags?
Sticky assignment: without it, a user might see "new checkout" on Monday and "control" on Wednesday. Their behavior data is polluted. You cannot attribute their conversion to either variant. Implementation: hash(userId + flagKey) → value in [0, 100]. Same inputs = same output. Deterministic without storing per-user state. Assignment is consistent across devices if tied to user ID (not cookie/device ID). Pitfall: if you change the flag key or bucketing logic mid-experiment, existing users get reassigned — experiment is invalidated. A/B testing requirements: sticky assignment, sufficient sample size (power analysis), minimum runtime (2 weeks for weekly seasonality), metric guardrails (ensure no regressions on secondary metrics), statistical significance before calling a winner.
4 / 5
What does trunk-based development have to do with feature flags?
Trunk-based development (TBD): all engineers commit to one main branch, ideally daily. Problem: features take weeks to build — incomplete code cannot be in main if it affects users. Flags solve this: create flag (default off), wrap all new code in flag check, commit daily to main (CI passes because flag is off everywhere), enable in dev/staging when testable, gradual production rollout when complete, remove flag after graduation. Benefits: no long-lived branches (no merge conflicts), CI always runs against integration point, main is always deployable. Complementary: short-lived branches (hours/days for review) are still used. Branch by abstraction: for large-scale refactoring without flags — create abstraction layer, implement new version behind it.
5 / 5
What is progressive delivery and how do feature flags enable it?
Progressive delivery: deployment (code on servers) is separated from release (users see the feature). Techniques: Feature flags: 0% → 1% → 10% → 100% user exposure. Canary release: deploy new version to a subset of servers; route percentage of traffic there. Metric-gated rollout: automated hold at each percentage if error rate or latency regresses. Tools: Argo Rollouts (automated canary analysis), Flagger (GitOps-integrated), LaunchDarkly (flag-based). Dark launch: execute new code path in production, discard the result — test performance without user impact. Ring-based deployment: internal users → beta users → production east → production global. Each ring is a checkpoint.