How would you implement a simple feature flag system?

WHAT THIS TESTS: This question probes whether you treat feature flags as dynamic runtime controls rather than static configuration. Interviewers want to see if you can decompose a minimal yet production-ready system into clear components, reason about client-server boundaries, and anticipate operational concerns like caching, availability, and lifecycle hygiene. At the senior level they are listening for distributed systems intuition: decoupling reads from writes, evaluating close to the user, and surviving control-plane failures without dropping traffic.

A GOOD ANSWER COVERS: First, the five core building blocks: a control service for authoring flag definitions, a persistent datastore, an API layer for serving those definitions, an SDK embedded in the application, and a continuous update mechanism such as polling or streaming. Second, the interaction model: the SDK connects to the API, caches the flag payload locally, and evaluates state near the user so that code paths resolve instantly without a network round-trip on every check. Third, operational discipline: flags should be short-lived and archived after rollout, names must be unique to prevent collisions, and the system should prioritize availability over consistency, falling back to cached values when the control service is unreachable. Fourth, sensible defaults: open by default is common, and sensitive targeting rules that rely on personally identifiable information should be evaluated server-side or carefully protected.

COMMON WRONG ANSWERS: A major red flag is describing flags as JSON or YAML files baked into the client bundle or server binary that require a rebuild and redeploy to change. That is configuration management, not feature flagging. Another weak pattern is proposing a synchronous network request to a flags service on every single isEnabled call, which introduces latency and a hard dependency. Candidates also stumble by ignoring lifecycle concerns, proposing a system where flags accumulate forever without TTLs or archival processes.

LIKELY FOLLOW-UPS: How would you handle targeting specific users or cohorts? How do you ensure a consistent user experience when flag definitions change mid-session? What happens if the control service goes down during a critical launch? How would you scale the read path independently from the write path? When should a flag be evaluated server-side versus client-side?

ONE CONCRETE EXAMPLE: Imagine a web application rolling out a new checkout flow. The server-side SDK initializes on startup by fetching the latest flag definitions from the API and refreshing them every thirty seconds. When a user hits the checkout endpoint, the application calls isEnabled new-checkout-v2 with a userContext against the locally cached state, resolving in microseconds. If the control service becomes unavailable, the SDK continues serving the last known state, preserving availability. After the rollout reaches one hundred percent, the flag is archived and the conditional code path is removed in the next sprint.

Source: docs.getunleash.io