How would you design a feature flag system (LaunchDarkly-style) at scale?
82 views
54 of 106
1
The problem
Question presented to candidate:
"We want to turn features on and off for millions of users without redeploying, and use it as a kill switch during incidents. Design a feature flag service like LaunchDarkly that thousands of services and apps can rely on."
What a strong answer should cover:
Splitting a control plane (dashboard, API, flag store, audit log) from a data plane (SDKs that hold the rules in memory and evaluate locally, with no network call per evaluation)
Delivery of changes: a streaming connection (server-sent events) that pushes deltas in well under a second, with polling as a fallback, and a full re-sync after a reconnect
Per-flag versions so that late or duplicated updates never roll a flag back, and an append-only audit log of who changed what
Failure behaviour: the flag service is never on the request path; a running SDK keeps its last known values, a cold start falls back to code defaults or a persistent cache or relay
Scale numbers: evaluations per second versus connections and change fan-out, the bootstrap storm when a whole fleet restarts, and client-side SDKs that receive evaluated values instead of rules
Clarifying questions expected:
Server-side services only, or browsers and mobile apps too (which cannot be trusted with the rules)?
How fast must a kill switch take effect, and what should happen if the flag service is down?
Do we need experiments and analytics on flag evaluations, or only on/off and rollouts?
Code / implementation expected: Optional โ the example models capacity, streaming versus polling lag, versioned updates and outage fallbacks.
feature-flags
platform
experimentation
2
Try it yourself
Sketch your approach before you read the solution. That is what the interview tests.
Stuck? Get a hint.
A short nudge toward the approach. It will not give the answer away.
3
Solution
Target Audience: Beginners to system design โ you know what a web service and a database are; every flag-system term is defined as it appears.
Difficulty: Medium
Verified with: Node 22.22 and Python 3.12 (both print identical output). The fleet, flag counts and latencies are stated assumptions; LaunchDarkly behaviour quoted below is from LaunchDarkly documentation (architecture overview and SDK contributor guide), checked October 2026.
How to read this doc: Every idea is explained in plain language first, then tagged with ๐ Interview term: so you also learn the words an interviewer expects. All numbers come from the example program; the Verified section quotes its full output. Targeting rules and percentage rollouts have their own page, advanced feature flags; this page i
The solution is hidden so you can try first
13 min read ยท 16 sections
4
Read the code
Flag delivery at scale: local vs remote evaluation, streaming vs polling lag, versioned updates and outage fallbacks