Your service can only disable a bad new code path by redeploying the previous build, which takes about 25 minutes end to end. What does putting that code path behind a runtime feature flag change about your recovery, and what has to be true of the flag for that improvement to be real?

## The problem the flag is solving When the only way to withdraw a change is to redeploy the previous build, your mitigation time is bounded by your delivery pipeline: rebuild or re-promote the artifact, roll it across instances, wait for health checks and connection draining. Twenty-five minutes is an ordinary figure for that, and during an incident every one of those minutes is user impact and error-budget spend. A runtime feature flag attacks the problem from a different angle. Instead of changing *which code is running*, it changes *which branch that code takes*. The new path and the old path both ship in the same artifact; a value read at request time decides which one executes. ```javascript // build-time constant: changing it means a redeploy const NEW_PRICING = true; // runtime flag: changing it means a config write if (flags.isEnabled('new-pricing', { userId })) { return newPricing(cart); } return legacyPricing(cart); ``` The first form is not an operational control at all — it is a compile-time decision wearing a flag's clothes. ## Deploy is not release The vocabulary matters in interviews. **Deploy** is the act of getting an artifact onto production machines. **Release** is the act of exposing a behaviour to users. Without flags the two are the same event, so the blast radius of a deploy is the blast radius of every change inside it, and the undo for both is the same slow mechanism. With flags they separate: you can deploy at any cadence, keep the new behaviour dark, and choose the moment — and the audience — for the release independently. Crucially, the *undo* for a release becomes a different, much cheaper operation than the undo for a deploy. This is why flags are treated as a release-safety practice and not merely a coding convenience. They give the on-call engineer a lever that can be pulled during an incident by someone who does not need to know how the build system works. ## The three conditions **Evaluated at request time.** If the flag value is read once at process start into a module-level constant or a cached singleton that never refreshes, flipping it changes nothing until the processes restart — and restarting every instance is a redeploy by another name. Real control means the value is consulted on the code path each time, or at least refreshed on a short interval that you know and can quote. **The off path still works.** A flag's promise is that turning it off returns you to the previous behaviour. That is only true if the previous behaviour is still exercised and still correct. Once a feature has run at 100 percent for months, the off branch has had no traffic, and it can rot silently — it may reference a column that was dropped, or produce a page that no longer renders. The flag looks like insurance and turns out to be a second, untested failure mode. **Propagation is fast and observable.** Flag changes usually reach instances by push (a streaming connection from the flag platform) or by poll (each instance re-fetching every few seconds). Either way there is a real number — a few seconds, sometimes tens of seconds — and you should know it, because during an incident the gap between "I flipped it" and "it took effect" is the window where people start making a second change on top of the first. You also want a signal that confirms the flip landed: the error rate turning over, or a metric that reports the effective flag value per instance. ## What the flag does not give you A flag does not make the change safe to ship untested; it makes it cheap to withdraw. It does not undo side effects that already happened — rows written in the new format, messages published to a queue, emails sent — so a flag guarding a write path is a weaker control than one guarding a read or render path, and you should say so when asked. It does not replace rollback either: a bad change that is not behind a flag, or a bad change in shared code that both branches run, still needs the deploy-level undo. And every flag has a cost. It is a branch in the code, a state in the test matrix, and an entry in an inventory somebody has to prune. The reason experienced teams still take that cost for risky changes is arithmetic: minutes of user impact avoided per incident, multiplied by the number of incidents where the lever gets pulled. ## How to answer it in an interview Give the number first — redeploy in tens of minutes versus a config change in seconds — then name the deploy/release split, then immediately volunteer the conditions. Candidates who stop after "flags let you turn things off quickly" sound like they have read about flags; candidates who say "and the off path has to still work, which is why we test both states" sound like they have owned one.