Feature Flag Rollout Simulator
Simulate feature flag rollout strategies. Watch how percentage-based rollouts, user targeting, and kill switches control which users see new features.
Continue with the guided workspace
Use the paired workspace to connect this guide's mental model with live component state, visible signals, and the outcome each step or scenario is meant to prove.
Feature flags decouple code deployment from feature release. New code ships hidden behind conditional gates, so a feature can be turned on for 1% of users, watched for problems, then ramped to 100% — or killed instantly with a single switch — without redeploying or restarting the application.
Mental Model
Feature flags decouple code deployment from feature release. Rather than deploying a giant merge block and hoping it works, code is deployed hidden behind conditional gates.
- Progressive Delivery: Releasing a feature gradually (e.g., to 1%, 5%, then 100% of users) to observe system health and conversion rates before exposing all users.
- Segment Targeting: Overriding percentages to force specific cohorts (like internal testers or beta users) into a new feature variant directly.
- Kill Switch: An emergency override that instantly disables a feature cluster-wide and redirects all traffic to the safe control variant without requiring a code redeployment or server restart.
Components and Why They Exist
Users Group
The Users Group represents active incoming traffic segments with diverse properties (such as location, email domain, or client device) used to test targeting rules. It emits request streams carrying user identifiers and cohort tags so the evaluator can route each user deterministically, displaying particle flows and conversion rates across variant targets.
Flag Service Registry
The Flag Service Registry stores evaluation rules and publishes dynamic configuration updates to application servers. It holds the ruleset mapping keys to variants, enforces percentage rollout buckets, and hosts the global kill switch, updating the configuration panel and sync propagation badges whenever a toggle changes.
App Instance (CONTROL)
The Control App Instance runs the stable legacy codebase, establishing baseline latency, error, and conversion metrics for comparison. It handles all requests that fall outside active rollout buckets or targeting overrides, updating request counters and error rates on the control server card.
App Instance (V1)
App Instance V1 executes the first candidate code path under percentage-based progressive exposure. It serves the new frontend or backend implementation to users whose consistent-hash bucket matches the V1 rollout slider, allowing you to compare its live metric cards against the Control baseline.
App Instance (V2)
App Instance V2 hosts a second candidate implementation to support multi-armed A/B/C testing. It processes transactions for traffic routed into the V2 bucket, surfacing distinct conversion metric changes or error spikes associated with that variant.
App Instance (V3)
App Instance V3 runs a third candidate version designed to test cohort targeting overrides such as internal QA or beta users. It handles requests from user groups mapped directly to the V3 rule, showing how targeted cohort traffic bypasses general percentage sliders on the status card.
Edge Cases and Misconceptions
- Flag configuration is not free: Feature flags add code complexity. Every flag introduces branching conditional checks (
if (flags.isEnabled('new-feature'))). If stale flags are not regularly removed from code after reaching 100% rollout, the codebase accumulates technical debt, increasing test surface areas and code confusion. - Stale cache synchronization: In client-side SDK mode, clients poll the flag registry at intervals (e.g., every 10 seconds). If you trigger a kill switch, clients will continue to execute the broken variant for up to 10 seconds until their local cache refreshes. Server-Sent Events (SSE) streaming resolves this by pushing updates in real-time.
- Targeting order evaluation: Rule evaluation order is critical. Targeting rules (e.g., “employees get V1”) must be evaluated before percentage rollouts (e.g., “10% of users get V1”). If percentage rollouts are checked first, an employee might randomly get assigned to Control, violating the targeting policy.
Common Questions
Why is consistent hashing critical for feature flag evaluations?
Consistent hashing guarantees deterministic user targeting. By hashing a user's ID combined with the feature flag's unique key (e.g. `hash(userID + flagKey) % 100`), the user is assigned a stable percentage integer. If the rollout is at 10%, only users with hash values <= 10 see the feature. When the rollout increases to 20%, the initial 10% of users are guaranteed to remain in the active variant rather than randomly jumping back and forth.
What are the trade-offs between client-side SDK evaluation and server-side API evaluation?
Client-side SDK evaluation downloads the complete ruleset to the client's memory once, allowing flag checks to execute locally in microseconds with zero network overhead. However, it introduces sync cache lag when rules change. Server-side API evaluation queries the flag service on every single request, providing real-time accuracy and zero stale caches, but adding network roundtrip latency to every user transaction.
How do flag dependencies introduce operational risk?
Flag dependencies occur when Flag B requires Flag A to be enabled. This creates a nested logical chain. If Flag A is disabled or rolled back during an incident, Flag B is instantly disabled too. This can lead to circular dependencies, unexpected dark launches, and technical debt that is extremely difficult to isolate and debug.
Why should stale feature flags be removed after rollout?
A completed rollout leaves conditional branches, targeting rules, and emergency overrides behind. If those flags stay forever, they increase test complexity and make incident response harder because engineers must reason about code paths that should no longer exist.