We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Microservices Architecture
A toggle in code that enables or disables a feature without redeploying. Lets you ship code to production behind a flag and turn it on for a percentage of users.
In short
A feature flag is a conditional in your code that turns a feature on or off at runtime without a new deploy. You ship the code to production behind the flag in its off state, then flip it on for everyone, for a percentage of users, or for a specific segment by changing a configuration value rather than shipping new code.
In short
A feature flag is a conditional in your code that turns a feature on or off at runtime without a new deploy. You ship the code to production behind the flag in its off state, then flip it on for everyone, for a percentage of users, or for a specific segment by changing a configuration value rather than shipping new code.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Feature Flag across a run of lessons, not one page. These 3 alone are about 73 minutes of step-by-step reading, every one with a quiz.
Deploying code to production without releasing features to users, decoupling deployment from release.
Toggle features on and off without deployment, kill switches for problematic features.
Provide reduced functionality instead of complete failure, fallbacks, feature flags, and cached responses.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Feature Flagspay once,
yours for life
A feature flag (also called a feature toggle) is a named boolean or value that your code reads before deciding which path to run. In the simplest form it is an if statement: if the flag new_checkout is on, run the new checkout code, otherwise run the old one. The flag's value lives outside the compiled code, in a config file, a database row, or a remote service, so you can change it without rebuilding or redeploying.
The point is to break the link between deploying code and releasing a feature. You can merge unfinished work into the main branch and deploy it to production every day, kept dark behind a flag set to off. The day the feature is ready, someone flips one value and it goes live. If it breaks, you flip it back in seconds instead of waiting for a rollback deploy that might take ten or twenty minutes.
Flags come in a few flavors. Release flags hide work in progress. Experiment flags split traffic for A/B tests. Ops flags act as kill switches for expensive or risky subsystems. Permission flags gate features to paid plans or specific accounts. They look the same in code but have very different lifetimes.
At its core a flag system has two parts: an evaluation point in your application and a source of truth for the flag's value. When your code asks is new_checkout enabled for this user, the flag SDK evaluates a set of rules against the current context (user id, plan, country, an internal flag) and returns true or false.
Percentage rollouts work by hashing a stable key, usually the user id, together with the flag name, mapping the hash to a bucket from 0 to 99, and turning the flag on if the bucket falls under the rollout percentage. Because the hash is deterministic, the same user always lands in the same bucket, so a user who got the new feature at 5% keeps it when you raise the rollout to 20%. That stickiness is what makes A/B tests valid.
Production systems do not hit a remote server on every check. SDKs from LaunchDarkly, Unleash, or Flagsmith stream the full ruleset to each app instance and cache it in memory, so an evaluation is a local microsecond-level lookup. Changes are pushed over a streaming connection or polled every few seconds, which is why a flip feels near instant across a fleet.
Reach for flags when you want trunk-based development with frequent deploys, when you need to roll a risky change out gradually and watch error rates, when you want a kill switch for a dependency that might fail under load, or when you run experiments. They pair naturally with canary releases and let product managers control timing without an engineer on standby.
The cost is complexity. Every flag is a branch in your code, so two flags create four code paths and your real test matrix grows fast. Flags that never get cleaned up rot into permanent dead branches; teams that do not enforce removal end up with hundreds of stale toggles nobody understands. Knight Capital's 2012 trading loss of about 440 million dollars came partly from reusing an old flag that re-activated dormant code on one of eight servers.
Treat flags as short-lived by default. Give each release flag an owner and an expiry, track them in a dashboard, and delete both the flag and the losing code path once a feature is fully shipped. Long-lived ops and permission flags are fine to keep, but label them so nobody mistakes them for cleanup debt.
LaunchDarkly
A dedicated feature management platform; streams flag rules to in-app SDKs so changes apply across a fleet in under a second.
Facebook Gatekeeper
Internal system that gates nearly every feature, letting them dark-launch to employees first, then ramp to a percentage of users before global release.
Netflix
Uses flags and its Spinnaker pipeline for canary rollouts, sending a slice of traffic to new code while watching metrics before going wide.
Unleash
Open-source feature flag service self-hosted by many teams; evaluates rollout rules locally in the SDK against a polled or streamed ruleset.
Both live outside the code, but a config setting usually tunes how a feature behaves (a timeout, a URL, a limit), while a feature flag decides whether a code path runs at all. Flags are typically temporary and tied to a release or experiment, whereas config tends to be long-lived.
Not in practice. Mature SDKs cache the full ruleset in memory and evaluate flags locally, so each check is a microsecond-level lookup with no network call. The real cost is code complexity and testing, not runtime latency.
The system hashes a stable key like the user id together with the flag name and maps it to a bucket from 0 to 99. The hash is deterministic, so a user always lands in the same bucket. When you raise the rollout percentage, users already inside stay inside, which keeps experiment results valid.
Yes. A database table of flag names and values plus an if check in code is enough to start. You only need a platform like LaunchDarkly or Unleash once you want percentage rollouts, targeting rules, audit logs, near-instant propagation across many servers, and a dashboard for non-engineers.
Give each release flag an owner and an expiry date, track all live flags in one dashboard, and delete the flag plus the dead code path as soon as a feature is fully rolled out. Keep only long-lived ops kill switches and permission flags, and label them clearly so they are not mistaken for cleanup work.
Canary Deployment
Rolling out a new version to a small percentage of users first, then gradually increasing. Like sending a canary into a coal mine to test for danger.
Blue-Green Deployment
A deployment strategy using two identical environments. Traffic switches from blue (current) to green (new) instantly, with easy rollback.
CI/CD
Continuous Integration and Continuous Deployment: automating the process of testing and deploying code. Push code, tests run, and it ships to production automatically.
Microservices
An architecture where an application is split into small, independent services that communicate over the network. Each service owns its own data and can be deployed separately.
Monolith
A single, unified application where all features share the same codebase and deployment. Simpler to start with but harder to scale individual parts.
Service Discovery
The mechanism by which microservices find and communicate with each other. Services register themselves and others can look them up by name.
This page explains the idea. The "Feature Flags" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Feature Flags lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Feature Flag in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
