How it works
Separate the control plane from the evaluation path. An authenticated management API stores flag definitions, targeting rules, rollout percentages, versions, and audit history. Application SDKs evaluate those rules using request context such as user ID or tenant ID.
Distribute configuration rather than making a remote call for every decision. SDKs fetch an initial snapshot, then receive updates through polling or a streaming connection. They validate each update and atomically replace their local snapshot; evaluation usually requires no network request.
Use deterministic bucketing for percentage rollouts. For example, hash a flag-specific seed and user ID into 10,000 buckets; a 5% rollout enables buckets 0 through 499. Keep the hash algorithm, input encoding, and seed stable across SDKs so the same user receives the same decision under the same configuration.
Define rule precedence explicitly, such as emergency disable, explicit exclusions, explicit inclusions, then percentage rollout. Choose the assignment unit deliberately: hashing tenant ID keeps an entire customer organization together, while hashing user ID allows finer-grained rollout.
Handle stale and missing configuration separately. An SDK can keep serving a last-known-good snapshot during a distribution outage, but a new process without a snapshot needs an explicit default. Track configuration age because a disconnected SDK cannot immediately receive an emergency disable.
Record configuration changes and observe behavior by flag version and variation. For experiments, record exposure when the selected behavior actually reaches the user, not merely when configuration is fetched. Give temporary flags owners and removal dates so obsolete branches do not accumulate.
A worked example
Rolling out a new search ranking path
Suppose a search service handles 40,000 requests per second and a new ranking path should reach 5% of eligible users. Each server evaluates a local configuration snapshot and hashes the flag seed plus user ID into 10,000 buckets, enabling buckets below 500. This selects approximately 5% of users, not necessarily 5% of requests. Increasing the threshold to 1,000 retains the original cohort and adds more users. Set a two-second propagation target for connected SDKs and monitor configuration age. During a distribution outage, servers retain their last valid snapshot. If the new path fails, disabling the flag stops new selections as updates arrive; already-running requests may still finish.
Trade-offs to say out loud
- Local speed versus configuration freshness
- Local evaluation avoids a serving dependency, but updates and emergency disables take time to reach every SDK.
- Availability versus safe defaults
- Last-known-good rules preserve availability, while safety-sensitive behavior may require expiration or a conservative fallback when configuration becomes too old.
- Targeting flexibility versus privacy
- Rich targeting increases rule complexity and may expose sensitive attributes or rules if distributed to untrusted clients.
- Controlled exposure versus measurement validity
- A percentage rollout limits exposure, but proving a feature helps also requires sound experiment assignment, exposure tracking, and analysis.
- Fast rollback versus irreversible effects
- Disabling a flag can stop future execution of a code path but cannot undo payments, emitted events, or incompatible data writes.
- Operational control versus code complexity
- Every retained flag adds behavior combinations to test and a configuration lifecycle to maintain.
When to reach for it
- The interviewer asks how to release a new code path gradually without deploying separately for each cohort.
- You need stable user or tenant assignment for an A/B testing platform.
- A feature needs an operational disable switch, with an explicit propagation target and outage policy.
- A staged migration needs controlled selection between compatible old and new paths, alongside separate correctness and cutover mechanisms.
How to bring it up in the interview
- Start with the assignment unit and freshness requirement: who must get a consistent decision, and how quickly must a change take effect?
- Draw the management API, configuration store, distribution layer, and local SDK separately; interviewers will probe whether a control-plane outage breaks application requests.
- Specify deterministic hashing and configuration versioning. Expect questions about cross-language SDK parity, out-of-order updates, and whether changing rollout percentages reshuffles users.
- Explain defaults for startup, stale configuration, and invalid updates rather than promising that a kill switch is instantaneous.
- Distinguish release control from authorization and experimentation: flags do not replace permission checks, and rollout percentages alone do not produce valid experiment results.
Common mistakes
- Making a synchronous flag-service request for every application request without accounting for latency and outage coupling.
- Choosing a fresh random value on every evaluation, causing users to switch behavior across requests.
- Claiming all instances change simultaneously despite polling delays, partitions, and disconnected clients.
- Treating a flag rollback as a way to reverse schema changes or external side effects.
- Sending confidential targeting rules to browser SDKs or leaving temporary flags in the code indefinitely.
Where it comes up
Interview questions where feature flags is part of a strong answer, and why.
Questions people ask
What is the difference between feature flags and canary deployments?
A canary deployment exposes a subset of traffic to a new application version. A feature flag chooses behavior within deployed code, often by user or tenant. They can work together: deploy code gradually, then enable its new behavior gradually.
How do you design a feature flag system at scale?
Keep configuration management separate from high-volume evaluation, and distribute versioned snapshots to SDKs that evaluate locally. Define deterministic assignment, update ordering, startup defaults, and stale-configuration behavior. Scale distribution by SDK connections and configuration update volume, rather than routing every decision through a central database.
Are feature flags the same as A/B testing?
No. Feature flags control which behavior runs; an A/B testing platform also needs valid assignment, exposure-to-outcome attribution, and statistical analysis. A rollout flag can support an experiment, but changing eligibility or assignment rules mid-experiment can undermine the results.