Q297: Feature Flags Experiments and Progressive Rollout Architecture

What Interviewers Want To Evaluate

Interviewers want to know whether you understand flags as production control systems, not just booleans.

They are checking targeting, evaluation location, hydration consistency, experiments, kill switches, cleanup, observability, permissions, and the difference between deploy and release.

Short Interview Answer

Feature flags let teams deploy code separately from releasing behavior. A good flag architecture defines where flags are evaluated, how targeting works, how variants are assigned, how flags interact with SSR and hydration, how experiments are measured, how kill switches work, and how old flags are removed. Flags reduce rollout risk, but unmanaged flags create complexity and hidden production states.

Detailed Interview Answer

A feature flag is a runtime decision point.

It can control:

visibility
behavior
traffic routing
experiment variant
permission
kill switch
configuration

The architecture question is not:

Can I add if (flag)?

The real question is:

Who decides the flag value, where is it evaluated, and how is it observed?

Deploy vs Release

Deploy means code is in production.

Release means users can experience the feature.

Flags let teams:

merge incomplete code safely
test internally
release to beta users
roll out by percentage
disable quickly
compare variants

This reduces blast radius.

Evaluation Location

Flags can be evaluated:

server side
edge side
client side
build time

Server-side evaluation protects secrets and avoids flicker.

Client-side evaluation supports instant changes but can expose flag names and targeting hints.

Build-time flags are simple but require rebuilds.

Edge evaluation can help with early routing decisions.

Hydration Consistency

SSR apps must avoid rendering one variant on the server and another in the browser.

Hydration mismatch examples:

server renders old nav
client reads flag and renders new nav
React detects mismatch
layout shifts
analytics double-counts exposure

The server and client need a consistent initial flag snapshot.

Targeting

Flags may target:

environment
user id
account id
role
region
browser
device
traffic percentage
internal staff
beta cohort

Targeting must respect privacy and permissions.

Do not put sensitive segmentation logic into public client bundles unless acceptable.

Experiments

Experiments need stable assignment.

If users switch variants randomly, measurements become invalid.

Track:

exposure
variant
conversion event
guardrail metric
sample size
duration
segment

Exposure should be logged when the user actually sees or can experience the variant, not merely when code loads.

Kill Switches

A kill switch disables risky behavior quickly.

Good kill switch examples:

disable expensive search suggestions
disable realtime collaboration
disable third-party script
disable new checkout UI
route traffic back to old API

Kill switches should be tested before incidents.

Flag Cleanup

Flags have lifecycle stages:

proposed
active
rolled out
cleanup due
removed

Unremoved flags create:

dead branches
test complexity
unknown production states
bundle bloat
confusing ownership

Every flag should have an owner and expiry expectation.

Observability

Events should include active flag variants.

This helps answer:

Did only variant B break?
Did the rollout increase errors?
Did one cohort see worse INP?
Did kill switch recovery work?

Flags and observability belong together.

Interview Framing

Say:

I would use flags to separate deployment from release, but I would design evaluation location, targeting, hydration consistency, exposure tracking, kill switches, and cleanup from the start.

Then add:

Flags reduce release risk only when they are observable and temporary.

Common Mistakes

• Evaluating flags differently on server and client.
• Treating experiments as random UI toggles.
• Forgetting exposure events.
• Leaving flags forever.
• Exposing sensitive targeting in the browser.
• Not testing kill switches.
• Adding flags without owners.

Learning Studio Example

Learning Studio could flag:

new side-by-side JS/TS console
PDF generation provider
search results ranking
progress qualification thresholds
new mobile navigation
AI review feature

For the console, the team could release to internal users first, monitor run failures, then increase rollout.

Final Mental Model

Feature flags are production controls.

They should make release behavior:

targetable
observable
reversible
measurable
temporary