How the interviewer opens it
“Design a feature flag platform that enables features for selected users, tenants, or a rollout percentage. Applications need fast flag decisions, even during a platform outage.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Flag rules
- Rollout identity
- Scale
- Read and write mix
- Latency
- Change visibility
- Consistency and availability
- Durability and startup
- Access control
- Scope limits
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Create and change boolean flags within a project and an environment
- Apply user overrides, tenant overrides, and percentage rules
- Evaluate flags with low latency during a control-plane outage
- Deliver flag changes to healthy applications within five seconds
Usually out of scope
- Browser and mobile SDKs
- Experiment analysis
- Arbitrary audience queries
- Billing
- Real-time evaluation analytics
What interviewers ask about
- Who receives a feature
- Services must agree on rollout membership for the same identity and configuration. Rule precedence must also remain clear across users and tenants.
- How edits reach applications
- An admin edit and its delivery span separate systems. Lost notices, old updates, and incomplete snapshots can leave applications with incorrect configuration.
- Decisions during an outage
- A fast decision cannot wait for an unavailable service. Existing processes, restarted processes, and new processes have different access to prior configuration.
Common mistakes
- The design calls the flag service for every application request.
- The percentage rule chooses a random value for each request.
- The SDK changes its hash seed when the flag version changes.
- The design treats an admin write as proof that every application uses the new value.
- The SDK waits for a network timeout before each flag decision.
- The design promises an immediate global shutdown during a network partition.
The bar by level
- Senior (L5/E5)
- Separates administration, distribution, and evaluation. Handles lost updates, version order, atomic snapshot replacement, restart behavior, and cross-language rollout consistency.
- Staff (L6+/E6+)
- Defines edit, publication, and adoption guarantees separately. Resolves offline shutdown limits. Addresses credential isolation, SDK compatibility, reconnect bursts, and delivery cost.