A real remote-config / feature-flag service (LaunchDarkly, Firebase Remote Config, Split) rolls a flag out to X% of users without a server round-trip per decision. Each device hashes its own stable user ID together with the flag's salt into a bucket 0–99, and the flag is ON only if that bucket is below the target percentage:
bucket(u) = FNV1a(userId + flagSalt) mod 100
enabled(u) = bucket(u) < rolloutPercent
Because bucket(u) never changes for a given salt, raising the percentage from 10% to 40% can only ever turn more users on — every user who was already ON stays ON. This is the monotonic sticky-rollout property that lets you dial a rollout up (or back down) without users randomly bouncing between the old and new behaviour mid-session.
- Sticky bucketing ON — the simulator uses the formula above. Watch "Consistency violations" stay at 0 no matter how you move the slider up.
- Sticky bucketing OFF — every user's ON/OFF state is instead re-rolled independently at the target probability on every change, exactly like a naive
Math.random() < p check with no memory. Users flicker on and off even when the percentage only goes up — a real bug class in flag systems that skip the hash step.
- New Flag Salt — simulates defining a *different* flag (or rotating the salt): buckets are re-shuffled, but stay fixed again under the new salt.
- Population size — resizes the simulated user base (rebuilds all buckets from scratch for the new users).
Real-world relevance: this exact bucket-and-threshold trick underlies gradual mobile rollouts, canary releases and A/B experiment assignment across virtually every production flagging system.