Feature Flags

## What a feature flag is, mechanically A feature flag (also called a feature toggle) is a piece of runtime configuration -- typically a boolean or a multi-variant value stored outside the compiled binary, in a config service, database row, or file -- that a running program reads to decide which code path to execute. Mechanically the pattern is simple: instead of shipping code that always runs the new logic, the code becomes a conditional such as `if (flags.isEnabled("new-checkout")) { newCheckoutFlow() } else { oldCheckoutFlow() }`. - **Both paths ship together.** The old and the new code paths are compiled into the same artifact and deployed together. - **The flag-management system decides.** A flag-management system -- an in-process SDK talking to a flag service, or something as simple as an environment variable or a database row read on each request -- tells the running process, at evaluation time, which branch to take. - **Flipping takes effect within seconds.** Flipping the flag from off to on requires no new deploy, no new build, and -- because the SDK typically polls or streams updates -- takes effect within seconds across the fleet. ## Why the pattern exists: deploy is not release The reason this pattern exists is to break the coupling between two activities that traditional deployment conflates: **deploy** (get new code running on production infrastructure) and **release** (make a capability visible and usable to real users). Without flags those two events are the same act -- merging and shipping code IS exposing it. That forces teams into two bad habits: 1. They hold back a feature branch for weeks until it is fully done, fighting merge conflicts, drifting from main, blocking other changes that touch the same files. 2. They ship half-finished work live and hope nobody notices. Flags let engineers merge continuously to a trunk branch -- the core practice of **trunk-based development** -- landing incomplete or risky code behind a flag that defaults to off. The code is *dark launched*: it runs in production, exercised by CI/CD or even synthetic traffic, but real users never see it until someone with release authority, often a product manager rather than an engineer, flips the switch, independent of any deploy pipeline. ## The trade-off The trade-off cuts on both sides. On the benefit side: - Releases become instant and instantly reversible: flip the flag back off in seconds, versus a code rollback plus redeploy that can take minutes and re-introduces deploy risk. - Releases can be targeted -- turn a feature on for five percent of users, for internal staff only, for one customer's account -- instead of all-or-nothing. - Deploy risk is decoupled from release risk, so "ship early, release later" becomes normal. On the cost side: - Every flag is a second code path that must be tested, and a codebase that grows flags without discipline accumulates complexity: nested conditionals across flags produce a combinatorial set of states that are, in practice, never all tested. - Flags also introduce a new runtime dependency, the flag-evaluation call itself. If it is a network call on every request that adds latency and a new failure mode; if it is a local cached SDK, it adds a small memory and CPU footprint plus a staleness window between someone flipping the flag and a given server instance seeing the update. ## Failure modes Failure modes show up in a few characteristic ways. 1. **Flag debt**, the most common in production: nobody deletes the flag once the feature is fully rolled out and stable, so the codebase keeps carrying a dead conditional and a dead old-code-path indefinitely. 2. **Another failure mode, evaluation inconsistency**: if flag state is read fresh per-request without any pinning, the same user can see the old and new UI on different clicks within one session, which is confusing and can break stateful flows such as starting a checkout with the old flow's fields and submitting to the new flow's handler. 3. **A third** is the flag service itself being unavailable or slow -- does the SDK serve last-known-good state, or block? ## Where it shows up in the wild A concrete, well-known real-world example: LaunchDarkly (and similarly Unleash, Flagsmith, or Split) is built specifically around this deploy/release split -- teams merge to main continuously, deploy on every merge via CI/CD, and product owners control the actual customer-facing rollout from a dashboard, entirely decoupled from when engineering shipped the code. Netflix and Facebook popularized this pattern at scale specifically to let thousands of engineers ship to a shared trunk daily without every commit being an instant, all-or-nothing customer-facing event.