Engineering Practice
Feature flags: multiple-choice review
Crux Multiple-choice synthesis across the feature-flags unit: deploy/release decoupling, the four flag types and their lifecycles, sticky percentage rollout, kill-switch, and flag debt.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each mirrors a call you make in a real release: not a definition to recite, but a tradeoff to weigh when the flag is live in production and traffic is on it.
Goal
Confirm you can connect deploy/release decoupling, the four flag types and their opposite lifecycles, sticky percentage rollout, the kill-switch, and flag debt — the synthesis the lesson built toward.
Quiz
Completed
A team merges a half-finished feature to main behind an off-by-default release flag and deploys it. A teammate objects that shipping unfinished code to production is reckless. What is the senior framing?
Heads-up Long-lived branches drift from main, accumulate merge conflicts, and force a big-bang release at the end. Decoupling deploy from release with an off flag is precisely how you ship incomplete code safely and keep trunk-based development.
Heads-up Decoupling is about the flag, not a separate environment. The same production binary holds the code dark and active; a flag check, not network isolation, gates exposure.
Heads-up Auto-releasing on deploy is the opposite of decoupling — it re-welds the two events. The release must stay a separate, deliberate flag flip.
Quiz
Completed
During a cleanup sprint an engineer finds a boolean flag that has served the same value to everyone for months and proposes deleting it and its dead branch. Before merging that PR, what is the one thing they must check?
Heads-up The 30-day-same-value heuristic flags candidates, it does not authorise deletion. A kill-switch is supposed to serve one value until you need it; deleting it removes your safety net.
Heads-up The exact percentage is not the deciding factor; the flag's purpose and lifecycle are. A permanent ops flag can sit at any value and still must not be deleted.
Heads-up Reference count tells you the cleanup blast radius, not whether removal is correct. A single-reference kill-switch is still a kill-switch you must keep.
Quiz
Completed
A 25% rollout reads error rate and latency as clean, but support reports users seeing the new UI flicker back to the old one between page loads. What is the defect?
Heads-up Widening the rollout changes how many users are in, not whether a given user stays in. A non-sticky 50% rollout flickers just as badly — the fix is deterministic per-user bucketing, not a higher percentage.
Heads-up Poll interval controls how fast a flag change propagates, not per-request consistency. Even with instant propagation, a non-sticky hash re-rolls each evaluation and flickers.
Heads-up Caching could explain a stale asset, but the symptom is a user flapping between variants on live evaluations — the signature of non-deterministic bucketing, which is exactly what a stable hash key fixes.
Quiz
Completed
Why do SDKs evaluate a flag as a local in-memory hash lookup with background sync, instead of asking the flag service per check?
Heads-up It is not merely an implementation convenience. Local evaluation changes the failure mode: a flag-service outage becomes graceful degradation to cached config rather than an outage of your own service.
Heads-up Background sync means there is a brief propagation window where servers can disagree. The benefit is latency and decoupling from the flag service, not instantaneous global consistency.
Heads-up Sticky bucketing is achieved by hashing a stable user key, done locally; centralising the call would not change stickiness and would reintroduce the network dependency.
Quiz
Completed
Ten independent boolean flags are live in a service. A bug appears in production that QA never reproduced in staging. How does the flag count bear on this?
Heads-up Independent toggles still combine into a multiplicative configuration space. Two flags whose code paths touch the same state can interact in a combination no single-flag test covers.
Heads-up It is combinatorial, not additive: N boolean flags yield 2^N configurations. Ten flags is over a thousand combinations, not ten.
Heads-up Exhaustively testing 2^N combinations is infeasible for any real N. The durable answer is to keep N small — delete flags promptly — not to try to test the whole explosion.
Quiz
Completed
The Knight Capital incident lost ~$440M in 45 minutes in 2012. Reduced to a flag-lifecycle lesson, what actually went wrong?
Heads-up The partial deploy was the trigger, but the loaded gun was a years-dead flag and its dead code still present and reusable. Reliable deploys help; deleting stale flags and their branches removes the ammunition.
Heads-up A kill-switch is good practice, but the incident's lesson here is upstream: dead code behind a stale, reused flag should never have been live to trigger. Type flags and delete release flags at end of life.
Heads-up It was not a rollout-percentage error. A long-dead flag was reused and woke dead code — a flag-debt and cleanup failure, not a ramp mistake.
Recap
The through-line: deploy and release are separate events, and a flag is the switch between them — ship dark, release by toggle. The four types (release, ops/kill-switch, experiment, permission) have opposite correct lifespans, so type is recorded, never guessed. Rollout must be sticky (hash a stable key into a fixed 0–99 bucket) or variants flicker and experiment data rots; evaluation is a local hash lookup so a flag-service outage degrades gracefully. And every live flag is a branch in production — N flags mean 2^N configurations — so the discipline is lifecycle: expire release flags, label kill-switches permanent, and delete stale flags before one becomes the next Knight Capital.