Build a feature-flag system with gradual rollouts and a kill switch
Turn features on and off without redeploying. Build a small flag service and a client SDK, roll a feature out to a percentage of your users, target beta users and segments, and kill a bad feature in one request. You will prove, over 10,000 simulated users, that the rollout hits its percentage and that the same user always gets the same answer.
- User and segment targeting, a kill switch, 13 passing tests, and a starter kit with every file
- Some Python (functions, dicts, lists) and basic terminal skills. If a flag service sounds like a lot, Build your own API in Python builds the FastAPI and SQLite groundwork this mission reuses, and Level 0's Terminal survival kit covers
cdand running commands. - uv, the Python runner from Level 0 (Install anything from GitHub, safely has the one-line install). Check with
uv --version. It fetches Python 3.13 and about 20MB of packages for you. - A code editor. VS Code ↗ is free; Notepad works at a push.
Why flags: shipping dark, releasing gradually
Understand the one idea the rest of the lesson builds on: a flag lets you decide whether a feature is on at run time, so shipping the code and switching the feature on become two separate events.
A feature flag is a named switch your code checks before it runs a feature. Instead of
if True:baked into a release, you writeif flags.is_on("new-checkout", user):, and something outside your code decides the answer. That one move changes how you ship.Normally, the code going live and the feature turning on are the same moment: you deploy, and every user gets the change at once. If it misbehaves, your only move is another deploy to take it back out, under pressure, while users hit the bug. A flag splits that into two. You ship dark: the new code goes to production with its flag off, reaching nobody. Later, on a calm afternoon, you turn the flag on for 1% of users, watch, then 10%, then everyone. This is decoupling deploy from release, and it is the reason flag systems exist.
Once deploy and release are separate, four things become easy, and you will build each one:
- A boolean flag turns a feature on or off for everyone, live, with no redeploy (step 3).
- A percentage rollout gives the feature to a share of users, say 20%, and ramps up as your confidence grows (step 4).
- Targeting gives it to specific users or whole segments, like your own account and every beta tester, regardless of the percentage (step 5).
- A kill switch turns a misbehaving feature off for everyone in one request, in seconds, without waiting for a deploy (step 6).
Two pieces make this work. A flag service holds the config (which flags exist, whether each is on, its percentage, its targeting) and lets you change it live. A client SDK sits inside your app, fetches that config, and answers
is_on(...)for a given user. The interesting logic is flag evaluation: taking a flag's config plus one user and returning a single yes or no. You will write that as a pure function and test it on its own before any server is involved.TipThe whole kit is in the lesson folder:server.py,flag_sdk.py,bucketing.py,flags.json,simulate.py, the two demo scripts,test_flags.pyandrequirements.txt. You can read along, or build each file as you go. Building it yourself is slower and teaches more.