System Design

Feature Flags

Design a feature flag service like LaunchDarkly or Unleash.

Functional requirements

• Engineers create boolean or multi-variant flags in a dashboard and change a flag's state or rules at any time (e.g., turn new-checkout on for 10% of users).
• Targeting rules match on attributes the application passes with each evaluation (user ID, plan, country) and can pin individual users or named segments to a variant.
• Application code asks an SDK a question like isEnabled('new-checkout', user) and gets an answer; SDKs exist for server-side languages and for mobile and browser apps.
• Percentage rollouts are sticky: the same user sees the same variant on every request and on every instance until the rule changes.
• A change saved in the dashboard reaches every running instance within seconds, and an audit log shows who changed what and when.

Non-functional requirements

• Evaluation is local: p99 evaluation latency under 1ms with no network call per evaluation; the SDK's initial ruleset fetch is the only remote call, under 200ms at p99.
• Availability over consistency for evaluation: instances may disagree on a flag's value for a few seconds while a change propagates, but no instance may ever evaluate against a partial or corrupted ruleset.
• A saved flag change is durable: once the dashboard confirms it, it is never lost or silently reverted, and prior versions of a flag's rules are kept for rollback.
• If the flag service is unreachable, applications keep evaluating from the last known good ruleset (or code-supplied defaults on cold start) and never block or crash.
• SDK keys are scoped to one environment (dev, staging, production) and revocable; a leaked key can read that environment's rules but never change a flag.

Scaling & constraints

• 2,000 customer organizations with ~500 flags each (~1M flags total); the serialized ruleset for one environment averages 200 KB and can reach 2 MB.
• 100,000 connected SDK instances at peak; the largest single customer has 8,000 instances on one production environment.
• ~10 billion evaluations per day across all customers (~500,000/sec at peak) versus ~5,000 flag changes per day: about one change per 2 million evaluations.
• A change must reach every connected instance within 5 seconds at p99; deploy waves reconnect ~20,000 SDKs within a minute.
• Evaluation events for analytics are sampled at 1%: ~100M events per day, ~200 bytes each.
• Audit history is retained for 2 years; flag count grows ~30% per year; an evaluation context carries 5-20 attributes, ~1 KB.

Out of scope

• Experimentation statistics and A/B test analysis.
• User accounts, SSO, and billing.
• Stale-flag detection and code reference scanning.
• The dashboard UI itself beyond the flag save API.