Feature Flags

The Decoupling

 deploy ≠ release:

 [code with flag] deployed to 100% of fleet
   └─ flag: new-checkout = OFF → behavior unchanged for users

 exposure becomes a RUNTIME decision:
 - flip ON for employees → beta cohort → percentage → all
 - flip OFF instantly when trouble appears (no rollback deploy!)

 if (flags.enabled("new-checkout", user)):
     return newCheckoutFlow()
 return legacyCheckoutFlow()

 the kill switch alone justifies the pattern:
 production incidents resolved by CONFIG FLIP in seconds,
 not by emergency rollbacks under pressure.

Flag Taxonomy (lifespans differ wildly)

Type	Example	Lifespan
release flag	gate new checkout rollout	days–weeks, then REMOVE
ops/kill switch	degrade expensive path under load	permanent fixture
experiment flag	A/B variant measurement	experiment duration
permission flag	beta-program access	long-lived
infrastructure toggle	new storage engine path	migration window

 the taxonomy exists because FLAGS ACCUMULATE:
 every dead flag is a branch of untested code and cognitive
 debt. discipline that works:
 □ every release flag gets a REMOVAL TICKET at creation
 □ quarterly flag audits: who owns what? delete the dead
 □ default-safe: unknown flag state → legacy behavior

The Engineering Around Toggles

 □ EVALUATION PERFORMANCE: flags checked on hot paths —
   cached local evaluation, no per-request RPC to flag service
   (SDKs poll/push config; evaluate from memory)
 □ CONSISTENCY within a user's session: sticky evaluation
   (hash by user-id) or a user flips variant mid-checkout ✗
 □ TESTING BOTH SIDES: flag-off paths rot silently —
   CI runs both configurations; contract tests per variant
 □ AUDIT TRAIL: who flipped what, when, why — flags are
   production changes and get change-management respect
 □ PERCENTAGE ROLLOUT + targeting rules reuse canary
   machinery conceptually: cohorts, gates, instant revert.

When Flags Become Harmful

 warning signs of flag sprawl:

 - combinatorial explosion: 10 interacting flags =
   1024 untested configuration states ⚠
 - nested conditionals: business logic buried under
   layers of toggles nobody dares remove
 - permanent "temporary" flags from years past
 - performance: evaluation logic itself measurable on profiles

 governance answers:
 □ flag BUDGETS per service; creation requires cleanup plan
 □ naming conventions encoding type+expiry (release.2024q3.checkout)
 □ automated detection of never-flipped / always-on flags

Interview Framing

“Ship features safely weekly without big-bang risk” scored shape: deploy-vs-release decoupling as the headline, kill-switch value demonstrated via incident scenario, taxonomy-with-lifespans table, hygiene disciplines (removal tickets, both-sides testing, sticky evaluation), sprawl dangers named proactively. Feature-flag questions test whether you see toggles as a LIFECYCLE DISCIPLINE rather than an if-statement — the cleanup culture is the seniority marker.