Designing a feature flagging service

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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).

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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?

ONE 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.