beginner9 min readUpdated 2026-06-08

Feature Flags: Progressive Delivery, Experiments and Safe Rollouts

Learn feature flags for system design: kill switches, percentage rollout, A/B tests, config stores, flag debt, consistency, and release tradeoffs.

Quick answer: Feature Flags: Progressive Delivery, Experiments and Safe Rollouts

Feature Flags: Progressive Delivery, Experiments and Safe Rollouts is covered here as a practical system design concept. Learn feature flags for system design: kill switches, percentage rollout, A/B tests, config stores, flag debt, consistency, and release tradeoffs. Use it to understand the Architecture Patterns idea, where it appears in production systems, and how to discuss it clearly in interviews.

Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.

Aspect	Details
What it is	Configuration switches that control whether a feature is active for specific users, percentages, or conditions — changeable at runtime without deployment
When to use	Progressive rollouts, A/B testing, trunk-based development, kill switches for operational safety, multi-tenant feature gating
When NOT to use	Stable features that do not need toggling — flags left in the code forever become technical debt (flag fatigue)
Real-world example	Facebook evaluates feature flags 10 trillion times per day via their Gatekeeper system, controlling every aspect of the user experience
Interview tip	Discuss flag lifecycle: create, test, roll out, clean up. Emphasize that flags are temporary — permanent flags become technical debt
Common mistake	Never cleaning up old flags — stale flags accumulate, making code harder to read and increasing the risk of flag conflicts
Key tradeoff	Deployment velocity and safety vs code complexity from conditional branches and the operational cost of managing flag state

Why This Matters

Without feature flags, deploying code means releasing it to all users simultaneously. If it breaks, you need a full rollback. Feature flags decouple deployment from release: code ships but is hidden behind a flag. This enables continuous deployment (merge to main, deploy daily), safe experimentation (A/B test pricing changes), and operational safety (turn off recommendation engine during Black Friday to save database load). Facebook, Google, and Netflix evaluate billions of flag decisions per day.

System architecture diagram for Feature Flags showing how services, databases, and caches connect — System architecture for Feature Flags

The Building Blocks

Boolean Flags: Simple on/off switches. The simplest flag type: isNewCheckoutEnabled = true/false. Controls whether the new checkout flow is active.
Percentage Rollout: Flags that activate for a percentage of users. Start at 1%, monitor, increase to 10%, 50%, 100%. Uses consistent hashing so the same user always sees the same variant.
User Targeting: Flags active for specific users, groups, or attributes. Enable for internal employees first, then beta users, then specific regions, then everyone.
A/B Testing: Flags that split users into variants (control vs treatment) to measure the impact of a change on business metrics (conversion rate, revenue, engagement).
Kill Switches: Flags designed for instant deactivation of expensive or non-critical features during incidents. Turn off recommendations during database overload.

Under the Hood

A feature flag system consists of a flag store (database or service like LaunchDarkly), an SDK in each application that evaluates flags, and a management UI for operations. When code reaches a flag check, the SDK evaluates the flag's rules against the current context (user ID, region, percentage bucket).

Step-by-step diagram showing how Feature Flags processes a request from start to finish — How Feature Flags works step by step

For percentage rollout, the SDK hashes the user ID to a number between 0-100. If the flag is set to 25%, users whose hash is 0-25 see the feature. This is deterministic — the same user always sees the same result. When the percentage increases to 50%, users 0-25 still see the feature (no disruption), and users 25-50 now see it too. This consistent hashing prevents users from flipping between variants.

The critical operational concern is flag evaluation performance. Facebook evaluates flags 10 trillion times per day — the SDK must be fast. Most SDKs cache the flag configuration locally and evaluate in-memory (microseconds). Configuration updates are pushed via streaming (SSE or WebSocket) so changes take effect within seconds, not on the next poll interval. For latency-critical paths, the local cache is essential — never call the flag service on the hot path.

How Companies Actually Do This

Facebook Gatekeeper evaluates 10 trillion flag decisions per day. Every feature, experiment, and operational control is managed through feature flags, from news feed algorithms to UI changes.

Comparison table for Feature Flags contrasting approaches, tradeoffs, and when to use each — Comparing key aspects of Feature Flags

Netflix uses feature flags for every deployment. Their system supports percentage rollouts, user targeting, and A/B testing. Kill switches disable non-essential features during infrastructure incidents.

Google uses Experiments framework for feature flags and A/B testing across all products. Chrome, Search, and YouTube all gate features behind flags before full release.

Common Pitfalls

Leaving old flags in the code indefinitely — after full rollout, remove the flag and its conditional branches. Stale flags create code complexity and potential conflicts
Using feature flags for long-term configuration — flags should be temporary (weeks to months). Permanent configuration belongs in config files or environment variables
Not testing both flag states — if the flag is off in production but never tested in CI, the 'off' path may be broken when you need to use it as a kill switch

Data flow diagram for Feature Flags showing how requests and responses move through the system — Data flow through Feature Flags

Interview Questions Worth Practicing

How would you implement feature flags for a service handling 100K requests per second?
What is the lifecycle of a feature flag, and how do you prevent flag accumulation?
How do feature flags enable both A/B testing and operational safety?

The Tradeoffs

Deployment Safety vs Code Complexity: Flags enable instant rollback and gradual rollout, but every flag adds a conditional branch. With 50 active flags, the code has 2^50 possible states.
Speed vs Governance: Self-service flag creation lets teams move fast, but without governance (naming conventions, expiry dates, ownership), flags accumulate into unmaintainable mess.
Client-Side vs Server-Side: Client-side flags enable instant UI changes without API calls but expose flag names to users. Server-side flags are more secure but require API round-trips.

Component diagram for Feature Flags showing each building block and its responsibility — Key components of Feature Flags

How to Explain This in an Interview

Here is how I would explain Feature Flags in a system design interview:

Feature flags let you toggle functionality at runtime without deployment. I would implement them as a three-layer system: a flag store (LaunchDarkly or a Redis-backed service), an in-app SDK that caches flags locally for microsecond evaluation, and a management UI. For a rollout, I start the flag at 0%, enable for internal users, then gradually increase to 1%, 10%, 100% using consistent hashing so users do not flip between variants. For operational safety, I use kill switches that disable non-critical features (recommendations, analytics) during incidents to reduce database load. The critical discipline is flag hygiene: every flag has an owner and expiry date. After full rollout, the flag and its conditional branches are removed. Stale flags are the primary cost of this pattern.

Interview preparation checklist for Feature Flags with key points to mention and mistakes to avoid — Interview tips for Feature Flags

Original DosiBridge notes for Feature Flags: Progressive Delivery, Experiments and Safe Rollouts

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Feature Flags: Progressive Delivery, Experiments and Safe Rollouts is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

Ownership Boundary: For Feature Flags: Progressive Delivery, Experiments and Safe Rollouts, decide the ownership boundary before choosing tools; otherwise the design looks clean but fails when feature changes.
Blast Radius: For Feature Flags: Progressive Delivery, Experiments and Safe Rollouts, decide the blast radius before choosing tools; otherwise the design looks clean but fails when flags changes.
Deployment Path: For Feature Flags: Progressive Delivery, Experiments and Safe Rollouts, decide the deployment path before choosing tools; otherwise the design looks clean but fails when feature changes.
Runtime Coupling: For Feature Flags: Progressive Delivery, Experiments and Safe Rollouts, decide the runtime coupling before choosing tools; otherwise the design looks clean but fails when flags changes.
Operational Handoff: For Feature Flags: Progressive Delivery, Experiments and Safe Rollouts, decide the operational handoff before choosing tools; otherwise the design looks clean but fails when feature changes.

Production review question

If a team adopts Feature Flags: Progressive Delivery, Experiments and Safe Rollouts, what observable signal proves it helped instead of only making the architecture diagram more fashionable?

Practical metric to track

Track feature-flags health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Feature Flags: Progressive Delivery, Experiments and Safe Rollouts, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.