Feature Flags for Resilience

In January 2019, a Knight Capital engineer deployed a new trading algorithm to production. Within 45 minutes, the algorithm had lost $440 million. The only way to stop it was to physically pull the servers offline. There was no kill switch.

Feature flags exist so that you never have to pull a server offline to stop bad code. The code ships dark. Both the old path and the new path are in the binary. A runtime toggle decides which one runs. When the new path misbehaves, a single toggle flips all traffic back to the old path in seconds. No rollback. No rebuild. No pipeline. Just one button.

LaunchDarkly, Split.io, and Flagsmith all built their companies on this idea. It sounds simple, but the engineering underneath, local evaluation, streaming updates, targeting rules, audit logs, is what makes it work at the speeds production incidents demand.

Most teams treat deploy and release as synonyms. You merge the PR, CI builds, the pipeline deploys, and users see the change. Feature flags break this assumption on purpose.

Deploy means the code is running in production. Both the new checkout flow and the old checkout flow are compiled into the same binary, sitting on the same servers.

Release means users can see the change. The flag decides which path runs. You can deploy on Monday and release on Thursday. Or deploy globally and release to 1% of users. Or deploy everywhere and never release at all if the monitoring looks wrong.

This separation is why feature flags are a resilience tool, not just a product management convenience. The blast radius of any change drops to the percentage of users who have the flag turned on.