Feature Flag Service

Problem statement (interviewer prompt)

Design a feature-flag service (LaunchDarkly-style). Define flags with targeting rules (per user / segment / percentage rollout), serve evaluations to SDKs in <10ms via push-based config updates, audit every change, and integrate with the experimentation platform.

flowchart LR
  ADM[Admin]
  CFG[Flag Service]
  KV[(Flag rules)]
  SDK([App SDK])
  ADM --> CFG --> KV
  SDK --> CFG
  CFG -. push .-> SDK

    classDef client fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
    classDef edge fill:#cffafe,stroke:#0e7490,stroke-width:1px,color:#0f172a;
    classDef service fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
    classDef datastore fill:#fee2e2,stroke:#991b1b,stroke-width:1px,color:#0f172a;
    classDef cache fill:#fed7aa,stroke:#9a3412,stroke-width:1px,color:#0f172a;
    classDef queue fill:#ede9fe,stroke:#5b21b6,stroke-width:1px,color:#0f172a;
    classDef compute fill:#d1fae5,stroke:#065f46,stroke-width:1px,color:#0f172a;
    classDef storage fill:#e5e7eb,stroke:#374151,stroke-width:1px,color:#0f172a;
    classDef external fill:#fce7f3,stroke:#9d174d,stroke-width:1px,color:#0f172a;
    classDef obs fill:#f3e8ff,stroke:#6b21a8,stroke-width:1px,color:#0f172a;
    class SDK client;
    class ADM,CFG service;
    class KV datastore;

flowchart TB
  subgraph Admin
    UI
    API
    CLI
  end

  subgraph Core
    FSVC[Flag Service]
    RULES[Rule engine<br/>targeting + percentage rollout]
    SEG[Segments]
    ENV[Environments]
    APP[Per-application config]
    AUD[Audit log]
    APPR[Approval / 4-eyes]
  end

  subgraph Store
    KV[(Versioned KV)]
    HIST[(Change history)]
  end

  subgraph Distribute
    BUS[Push channel]
    POP[Edge POPs]
    LP[Long-poll / SSE]
    SDK_LOCAL([SDK local cache + fallback])
  end

  subgraph Clients
    APPCL[Apps]
    SERVER([Server-side SDKs])
    EDGE[Edge worker eval]
  end

  subgraph Safety
    KILL[Kill switch]
    DEFAULT[Default-OFF for new flags]
    LIMIT[Per-tenant limits]
  end

  Admin --> Core --> Store
  Core --> Distribute --> Clients
  Safety --- Core

    classDef client fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
    classDef edge fill:#cffafe,stroke:#0e7490,stroke-width:1px,color:#0f172a;
    classDef service fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
    classDef datastore fill:#fee2e2,stroke:#991b1b,stroke-width:1px,color:#0f172a;
    classDef cache fill:#fed7aa,stroke:#9a3412,stroke-width:1px,color:#0f172a;
    classDef queue fill:#ede9fe,stroke:#5b21b6,stroke-width:1px,color:#0f172a;
    classDef compute fill:#d1fae5,stroke:#065f46,stroke-width:1px,color:#0f172a;
    classDef storage fill:#e5e7eb,stroke:#374151,stroke-width:1px,color:#0f172a;
    classDef external fill:#fce7f3,stroke:#9d174d,stroke-width:1px,color:#0f172a;
    classDef obs fill:#f3e8ff,stroke:#6b21a8,stroke-width:1px,color:#0f172a;
    class SDK_LOCAL,SERVER client;
    class EDGE edge;
    class FSVC,RULES,SEG,ENV,APP,APPR,BUS,POP,LP,APPCL,KILL,DEFAULT,LIMIT service;
    class KV,HIST datastore;
    class AUD obs;

Glossary & fundamentals

Concepts referenced in this design. Each row links to its canonical page; the tag column shows whether it is a high-level (HLD) or low-level (LLD) concept.

Tag	Concept	What it is	Page
HLD	CDN	edge caching for static assets	cdn
HLD	Realtime protocols	WS / SSE / polling / gRPC streaming	realtime-protocols
LLD	Async models	futures / async-await / coroutines / actors	async-models

Quick reference

Functional

• Boolean / multi-variate flags.
• Targeting rules (user, attribute, segment).
• Percentage rollout, sticky.
• Kill switch, scheduled rollouts.
• Per-environment.

Non-functional

• Evaluation latency < 1 ms with local SDK.
• Push propagation < 10 s.
• Highly available reads even on control plane outage (stale cache OK).

Trade-offs

• Local evaluation vs server evaluation: local is fast; server centralizes audit.
• GitOps vs UI flags: GitOps for release flags, UI for ops kill switches.

Refs

• LaunchDarkly architecture, GrowthBook, Unleash, Flipt.
• "Feature flags considered harmful" critiques.

FAQ

How does a feature flag service work?

Developers define flags with targeting rules. Client and server SDKs evaluate locally using rules pushed from the server, so checks are sub-millisecond and offline-safe.

What is the difference between a feature flag and a config service?

Feature flags target users with rules and percentages and tie into experiments. A config service holds operational tuning shared by all instances of a service.

How does gradual rollout work?

Each user is hashed into a 0 to 100 bucket. The flag rule includes everyone below the rollout percentage, so increasing the percentage lets more users see the change.

How are feature flag updates pushed in real time?

SDKs maintain a streaming connection to the flag service via SSE or WebSocket. When a flag changes, the server pushes a delta, and the SDK applies it within seconds.

Why are kill switches important?

Kill switches let on-call engineers disable a broken feature in seconds without a deploy, dramatically reducing mean time to recovery during incidents.

How do feature flag systems prevent flag debt?

Platforms track flag age, stale flags, and code references. Owners are reminded to clean up flags after rollout finishes so the codebase does not accumulate dead toggles.