Loading…

Design a Feature Flag Platform (LaunchDarkly) - SystemRound

Design a Feature Flag Platform (LaunchDarkly)

mediumSystem design45 min5 stagesPro

Asked atLaunchDarklyAtlassianStripeNetflixDatadogUberSplit

Design a feature-flag and rollout-control platform like LaunchDarkly. Applications ask "is this feature on for this user?" millions of times a second, so the answer has to be instant — which is the whole twist: evaluation happens locally inside the SDK, not as a network call. The hard system-design surface is the control plane: distributing rule changes to ~100M long-lived SDK connections within seconds, bucketing percentage rollouts deterministically so a user never flickers, and staying available for customer apps even when your own service is down.

Best once you can already structure a clean answer and want sharper trade-off pressure.

What this problem tests

Control-Plane CRUDSDK Streaming ContractTargeting Model & AuthCore ComponentsLocal Evaluation (topology)Change-Propagation Flow

Round shape

5 stages

Time budget

45 min

Feedback loop

Grade anytime

Guided practice·Primary loop

Guided practice

Workspace-first, hints visible, stage retry available. The cheap, repeatable loop — build the answer shape before you take it under pressure.

Stage-by-stage workspace instead of a blank page.
Grade one stage or the whole answer whenever you want.
Compare your reasoning against reference criteria and model answers.

Solve once, compare against the checklist, then come back to the weak stage instead of starting over.

Mock interview·Pressure test

Mock interview

Strict timer, hints hidden, debrief deferred to the end. Use this once you can already structure a clean answer and want to pressure-test pacing and pushback.

Best once the answer shape is already in your head.
Pressure-test pacing, pushback handling, and communication.
Use diagnosis after the interview for exact misses and next study steps.

Best after one structured rep · timed · focused on pacing and communication.

Requirements

This is the framing pass. A strong answer quickly defines what the system must do, what quality bar it has to hit, and the numbers that will justify the rest of the design.

First 5 min of the round

What must exist

Functional Requirements

5 items

1Evaluate a flag for a user/context and return a variation (boolean or multivariate).

2Targeting: attribute rules, named segments, and percentage rollouts.

3Edit a flag in a dashboard and have running apps pick it up in near real-time.

4Kill-switch to disable a feature instantly, everywhere.

5Audit log + rollback to a previous version (nice-to-have).

What good looks like

Non-Functional Requirements

4 items

1Evaluation is local and in-process in the SDK — p99 < 1ms with no network call per check — because apps call `isEnabled()` on nearly every request and inside hot loops.

2That inverts the problem: the distributed-systems work is not evaluation, it is distributing rule changes to running SDKs in p99 < 5s.

3A control-plane outage must not break customer apps — they keep serving the last-known-good ruleset.

4Percentage bucketing must be deterministic so a user never flickers in and out.

Numbers to anchor the design

Scale Estimation

4 items

15,000 orgs, ~100M concurrently connected SDK clients, ~50B evals/day.

2The 50B evals are local and never touch us — they don't size the backend.

3The real number is 100M persistent connections: at ~100K connections/node that's ~1,000 fan-out nodes.

4A few KB per connection is hundreds of GB of RAM just to hold the sockets.

How the round unfolds

Each stage has a distinct job. Treat them like separate deliverables instead of one giant answer, and the round becomes much easier to navigate.

4 design stages · 40 pts after framing

🔌

Stage 2~5 min10 pts

API Design

Define the contract clearly: the endpoints, auth boundary, error semantics, and the one or two decisions that matter most.

What you should produce

Now define the API. There are two very different surfaces here: the dashboard/control-plane CRUD for editing flags, and the SDK contract that strea...

Strong answers cover

Control-Plane CRUDSDK Streaming ContractTargeting Model & Auth

🏗️

Stage 3~10 min10 pts

High-Level Architecture

Lay out the main components and trace the write path, read path, and any async path cleanly.

What you should walk through

Walk me through the architecture.

Strong answers cover

Core ComponentsLocal Evaluation (topology)Change-Propagation Flow

📝

Stage 4~10 min10 pts

Data Model & Versioning

Let's get concrete about data. What's the schema for flags, environments, segments, and rules? How do you version a ruleset so you can roll back, and crucially — how do you bucket a percentage rollout so it's deterministic and sticky?

Prompt you should be ready for

Let's get concrete about data.

Strong answers cover

Schema & Store ChoiceVersioning & RollbackDeterministic Bucketing

📈

Stage 5~15 min10 pts

Scaling & Deep Dive

Name the first bottleneck, failure modes, and the trade-offs that keep the system fast and reliable under pressure.

What you should pressure-test

Let's deep dive. Where does this bottleneck first as you scale to 100M connections? Walk me through the connection fan-out, a reconnect storm, the...

Strong answers cover

Connection Fan-Out BottleneckResilience / Last-Known-GoodKill-Switch & Observability

What a strong first rep looks like

Scope clearly

Translate the prompt into concrete requirements, scale, and trade-offs before drawing architecture.

Stay stage-specific

Give APIs in the API stage, data models in the storage stage, and failure modes in scaling. Don't blur them together.

Iterate fast

Grade early, compare to the reference reasoning criteria, fix the biggest misses, and re-submit the weak stage instead of starting over.