Your feature flag service becomes unavailable. What happens to the fleet, and what should happen?
Show the full answer Hide the answer
What the interviewer is testing
Whether a flag service in the request path has been recognised as a hard dependency.
What typically happens
If flags are evaluated remotely per request, every request now fails or hangs waiting on an unavailable service. A management system has taken down the product.
If the client library caches with a short TTL, the fleet operates on cached values until they expire, then the same failure with a delay.
If it fails open to defaults, behaviour changes fleet-wide and unpredictably — features that were off turn on, or vice versa — which can be worse than an outage because it is silent and inconsistent.
What should happen
Local evaluation against a cached ruleset. The client fetches the full flag configuration, evaluates locally with no network call per request, and refreshes in the background.
Indefinite fallback to the last known good configuration. If refresh fails, keep using what you have — for hours or days. Flag values change rarely; stale flags are almost always harmless, and failing is not.
A safe local default compiled in, for a process starting fresh with no cached configuration and no service available.
Alert on staleness, so operating on old configuration is visible rather than silent.
With these, a flag service outage means flags cannot be changed, which is an operational inconvenience rather than an incident.
The general principle
Do not put a control plane in the data plane's request path. Feature flags, configuration services, secret managers and service registries are all management systems — more complex and less reliable than the data planes that depend on them — and a per-request dependency on any of them caps availability at the product of both.
What a strong answer adds
The related risk: kill switches must work when things are broken. An operational flag used to shed load or disable a failing feature is needed precisely during an incident, so if the flag service is unavailable during that incident, the mitigation is unavailable too. That argues for a separate, very simple, highly available path for operational flags — and for testing it.
Common weak answers
Adding retries. Making the flag service highly available, which reduces the probability without removing the dependency.