Engineering Practice
Feature flags: code and targeting reading
Crux Read real flag-evaluation code and a targeting rule, predict the behaviour or the bug, and pick the highest-leverage fix a senior engineer makes first.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitThe flag check, the bucketing hash, and the targeting rule are where flag systems quietly go wrong. Read the snippet, predict what production does with it, then choose the fix a senior would make first.
Goal
Practise the loop you run on every flag review: read the evaluation path, spot the consistency or fail-open bug, and reach for the structural fix — sticky bucketing, a safe default, a removal ticket — before adding more flags.
Snippet 1 — the rollout check
function inRollout(flag, user) {
// 25% rollout: roll a fresh random number per call
return Math.random() * 100 < flag.rolloutPercent;
}
if (inRollout(newCheckout, user)) {
return renderNewCheckout(user);
}
return renderOldCheckout(user); Quiz
Completed
A 25% rollout uses this check. What goes wrong in production, and what is the fix?
Heads-up Off-by-one on the boundary moves one bucket; it does not cause the symptom. The defect is that the assignment is random per call rather than a deterministic function of the user, so it is not sticky.
Heads-up Random is cheap; speed is not the issue. The issue is correctness: a non-deterministic per-call roll means no per-user stickiness. The fix is a stable hash, not caching the roll.
Heads-up A per-evaluation network call would add latency and a hard dependency. Stickiness comes from hashing a stable user key locally, deterministically — no network round-trip per check.
Snippet 2 — the kill-switch path
async function chargeCard(order) {
const enabled = await flags.evaluate("payments-enabled", order.user);
if (!enabled) {
throw new Error("payments disabled by kill-switch");
}
return gateway.charge(order);
}
// flags.evaluate throws if the flag service is unreachable Quiz
Completed
This wires a kill-switch around payments. What is the production hazard, and what is the senior fix?
Heads-up The polarity is correct — disabled means do not charge. The hazard is that a network failure in evaluate throws and blocks the path, turning the flag service into a single point of failure.
Heads-up The intentional disable path can legitimately reject the charge. The real defect is the per-call network dependency that fails the path when the flag service is down.
Heads-up A second check adds another network dependency without fixing the first. The structural fix is local evaluation with a safe default so the flag service is never on the critical path.
Snippet 3 — the targeting rule
flag: new-dashboard
rules:
- if: user.plan == "enterprise"
serve: on
- if: user.betaOptIn == true
serve: on
- rollout:
percent: 10
stickyBy: user.id
default: off Quiz
Completed
An enterprise user who has also opted into beta loads the dashboard. Which rule decides their variant, and what general property does this config rely on?
Heads-up Targeting does not AND every rule. Rules are evaluated in order and the first match serves; an enterprise user is on regardless of the later beta and rollout rules.
Heads-up There is no implicit priority for rollout rules. Precedence is purely positional — the enterprise rule comes first and short-circuits before the rollout is reached.
Heads-up Multiple matches are not ambiguous; the first match wins and the default only applies when no rule matches. This user matches the enterprise rule first.
Snippet 4 — the stale flag in code
// added 2023-02 for the checkout-v2 release, ramped to 100% in 2023-03
if (flags.isEnabled("checkout-v2")) {
return renderCheckoutV2(cart);
} else {
return renderCheckoutV1(cart); // V1 no longer maintained
} Quiz
Completed
It is now a year later; checkout-v2 has served on to everyone since 2023-03 and V1 is unmaintained. What is the correct action and why?
Heads-up It is not harmless. The branch still evaluates, clutters the code, and the unmaintained V1 path can be reused or accidentally re-enabled — exactly how a stale flag woke dead code at Knight Capital.
Heads-up Re-enabling a year-old, unmaintained path resurrects dead code against stale assumptions. A release flag should not be silently repurposed as ops; that needs a deliberate decision, an owner, and maintained code on both sides.
Heads-up Sending traffic to an unmaintained path to keep it warm institutionalises the debt. The right move is to delete V1 and the flag, not to preserve a path nobody maintains.
Recap
Every flag review reads the same way: a rollout check must hash a stable key into a fixed bucket or it flickers; a kill-switch must evaluate locally with a safe default or the flag service becomes a hard dependency that fails your hot path; targeting rules are order-sensitive and the first match short-circuits, so rule order is precedence; and a release flag at 100% with an unmaintained other branch is flag debt to delete, not config to keep. Read the evaluation path, fix the structure, then re-review.