Designing a feature flagging service
System design for low-latency config delivery and HA.
Control plane (UI, store, targeting), SDKs that cache flags locally for zero-latency evaluation, streaming/CDN delivery for near-real-time updates, and stale-flag lifecycle tooling.
What's really being asked
Whether you can design a feature-flag system that delivers low-latency evaluation, high availability, near-real-time updates, and a maintenance story, balancing all four.
The full answer
Core components split into a control plane and a data path. The control plane is the management UI, the configuration store (flags, variations, and targeting rules such as percentage rollouts and user segments), an audit log, and an API. The critical design choice for latency and availability is local evaluation: client SDKs download the full flag ruleset and evaluate flags in memory per request, so there is no synchronous network call on the request path. This keeps evaluation microsecond-fast and means the application keeps working even if the flag service is unreachable, falling back to the last cached config or defaults. For near-real-time updates, push changes to SDKs via a streaming connection (server-sent events or websockets) or a CDN-backed poll with short TTLs, so a flag change propagates in seconds without redeploys. Make the delivery layer globally distributed and the config highly cacheable for availability. For stale-flag debt, assign every flag an owner and a purpose, set expiry or review dates, track which flags are still being evaluated (usage telemetry), surface long-lived or unused flags in dashboards, and build cleanup into the workflow (tickets, alerts, or even blocking new flags until old ones are retired).
The mistakes people make
Doing a synchronous network call to the flag service on every request, which adds latency and makes the service a single point of failure for the whole app. Ignoring offline or fallback behavior. Treating flags as fire-and-forget with no lifecycle, leading to thousands of stale flags.
What usually comes next
How do SDKs stay consistent during a rollout? How do you handle flag evaluation for new users with no cached config? How do you prevent a bad flag config push from breaking everyone at once?
A concrete example
Each service embeds an SDK that streams the flag ruleset and evaluates locally, so toggling a flag in the UI propagates to all instances within seconds with no redeploy and no per-request latency. A weekly job flags any toggle older than 90 days with no variation changes and files cleanup tickets to its owner.
Interview question
Why do mature feature-flag systems evaluate flags inside a client SDK using a locally cached ruleset instead of calling the flag service per request?
- a.To force every request to validate against the central server for consistency
- b.To keep evaluation low-latency and available even when the flag service is unreachableCorrect
- c.Because SDKs cannot make network calls at all
- d.To avoid ever needing to update flag configurations
Why? this is the answer
Local in-memory evaluation removes per-request network latency and avoids making the flag service a single point of failure, falling back to cached config if it is down. A synchronous remote check per request is the anti-pattern this avoids.
Just read this? Test yourself on what you have been reading.
- #system-design
- #feature-flags
- #high-availability
- #sdk
- #technical-debt
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on system-design — each one lists the topics its interview covers.
See open roles