Feature Flags: What and Why?

What are feature flags?

Feature flags are ways to control how new features or code changes are rolled out. They're used in various scenarios:

Gradual Rollouts

Once an engineering team gets to a certain size, it becomes extremely likely for bugs to surface during deployments, causing the site or application to fail for almost every user -- hence requiring rollbacks and post-mortems. Imagine you have 10s or 100s of engineers checking in code every day. It's just a matter of time before rollbacks start creeping in due to a particular code change requiring the entire release to be rolled back.

One way to address this is by controlling the blast radius of code changes by doing something as follows in your business logic:

if is_on('NEW_FEATURE'):
  # new logic
else:
  # existing logic

The main advantage here is that we can control the percentage of users for whom new logic will run and can ramp that up over time. Usually, you would start with 0%, ramp up the rollout, and monitor the impact of the change by looking at relevant dashboards. The moment you observe new exceptions, performance degradation, or error increase, you would then turn off the feature and continue business as usual. Without a feature flag system, you would be forced to rollback the change. You can have canary to minimize impact, but you don't have much control. There could be many code changes being rolled out and sometimes it's hard to know what change caused what.

Gating Features

It's quite common to enable or disable features based on some attribute associated with the user, company, location...etc. For example, a new feature is rolled out to a selected set of beta-test users, internal users, or some other set of IDs. Instead of adding an attribute on the user per feature to be included/excluded, this can be delegated to a feature flag system where that mapping is dynamic and can be updated on the fly (i.e., new beta test users).

Kill Switch

In case of emergencies, it's sometimes better to have a degraded user experience than a full site outage. So, it's useful to turn off certain features to reduce load on the backend. For example, imagine a scenario where the database is overloaded. The load is coming from unoptimized queries that are associated with a particular feature (i.e., search). It's better to turn off search temporarily to fix the issue as opposed to rendering the entire website unusable. Assuming the search feature code is gated by a feature flag, this can be easily done. In fact, it could be even ramped down and not necessarily turned off immediately.

Try it yourself

Trying FeatureGuards is free and doesn't require any credit card. Check out our documentation too if you're interested in learning more.
Once you start using feature flags, you will never look back. Would love to learn your thoughts in the comments below.