← Back to all questions
SeniorStaffPlatformExperimentation
Design a Feature Flag System
Roll out features safely with targeting, gradual exposure, and instant kill-switches.
100% free · No login required
WHAT THIS QUESTION TESTS
·Targeting rules and evaluation latency
·Consistency of flag state across services
·Safe rollout, audit, and instant rollback
★ STAFF-LEVEL SIGNALS
★Treats every flag as a potential outage: safe defaults, kill-switches, and a bounded blast radius.
★Chooses local evaluation to remove a network hop and a hard dependency from the request path.
★Defines propagation guarantees (eventually consistent in seconds) and the staleness window.
★Adds experimentation: consistent bucketing, exposure logging, and metrics wiring for valid A/B tests.
1
The prompt
Design a feature flag platform that lets teams roll out features safely. It supports targeting rules (by user, segment, or percentage), gradual exposure, instant kill-switches, and experimentation — and must evaluate flags with very low latency across many services without any single flag change risking an outage.
2
Senior-level outline
- Clarify scope: boolean vs multivariate flags, targeting dimensions, and who edits flags.
- Split the control plane (dashboard + store) from the data plane (evaluation in each service).
- Ship flag rulesets to SDKs that evaluate locally; stream updates so changes propagate in seconds.
- Stable percentage rollout by hashing userId so a user stays in the same bucket.
- Always define a default / fallback value used when config can’t be fetched.
- Persist an audit trail of who changed what and when.
3
Common mistakes
- Evaluating flags with a synchronous remote call on every request — adding latency and a failure dependency.
- No default value, so an outage in the flag service breaks the product.
- Random percentage rollout that re-buckets users on every evaluation.
- Ignoring audit trails and who can flip a flag in production.
- Never removing old flags, leaving dead branches everywhere.
◇
AI engineering connection
Feature flags are how AI features ship without blowing up production. Prompt changes, model upgrades, and new retrieval strategies all roll out behind flags with percentage exposure and instant kill-switches — and increasingly the launch is gated on eval results, not just a toggle. The same control-plane / data-plane split and safe-default thinking is what interviewers probe when they ask how you would A/B two prompts, roll back a regressed model, or canary a new agent safely.
★
Rubric — Senior vs Staff
Dimension
Senior signal
Staff signal
Requirements
Captures targeting and rollout needs
Separates flag types, defines ownership and approvals
Architecture
Control plane vs data plane
Justifies local vs remote evaluation tradeoff
Latency
Caches flag state
Removes the hot-path network hop entirely
Consistency
Pushes updates to services
Defines propagation / staleness guarantees explicitly
Reliability
Has a fallback value
Kill-switches, bounded blast radius, safe defaults
Experimentation
Percentage rollout
Stable bucketing + exposure logging for valid A/B
Ownership
Mentions audit
Owns lifecycle, cleanup, governance, rollback
★ MORE WALKTHROUGHS
Want more breakdowns like this?
Join free early access for upcoming RAG, LLM eval, agents, and AI infrastructure walkthroughs.