Feature Flags System Design
How to turn features on and off without a deploy: targeting rules, stable percentage rollouts, fast local evaluation, kill switches, and keeping old flags from piling up.
Overview
A feature flag (also called a feature toggle) is a switch in the code that decides at runtime which path to run. The new code ships to production turned off. Later, someone changes the flag's setting, and the feature appears for some or all users, with no new build and no deploy.
That split is the whole point: deploying code and releasing a feature become two separate steps. Teams can merge unfinished work behind a flag, turn a feature on for staff first, roll it out to 1% of users and then more, and turn it off in seconds if something breaks.
Designing the system behind the switch is a common interview question. The hard parts are not the if statement. They are evaluating flags fast on every request, giving each user the same answer every time, getting a change to every server quickly, behaving safely when the flag service is down, and removing flags once their job is done.
What you will be able to do
- Explain the kinds of flags and why each one lives for a different length of time.
- Design flag evaluation that runs in memory, with no network call per request.
- Build a percentage rollout that keeps each user in the same group as it grows.
- Say how quickly a kill switch takes effect, and how to make it faster.
- Plan the life of a flag, from creation to deleting its code.
Key concepts
- Deploy vs release
- Toggle point and toggle router
- Targeting rules
- Percentage rollout
- Local evaluation
- Streaming and polling
- Kill switch
- Safe defaults
- Flag debt
- OpenFeature
Interview questions
- Design a feature flag system that adds almost no latency to each request.
- How does a percentage rollout keep each user in the same group?
- An incident is traced to a new feature. How fast can a flag turn it off, and how do you make it faster?
- What happens if the flag service goes down?
- When would you evaluate flags on the client, and when on the server?
- How do you stop old flags from piling up?
- Can the same system run A/B tests?
- How would you avoid lock-in to one flag vendor?
Sign up free to read the full topic
More System Design topics
Start free on Cariara · Coding problems · System design studio