When a feature flag system does a percentage rollout, say enabling a flag for 10% of users, how does it decide which specific users fall in that 10%, and why must that decision be consistent across repeated evaluations for the same user rather than random each time?

## How a user lands inside the slice Mechanically, a percentage rollout answers one question per request: does this particular user fall inside the enabled slice? The standard technique is **deterministic hashing** rather than a coin flip. Step by step: 1. The flag system takes a **stable identifier** for the user -- a user ID, device ID, or session key. 2. It combines that with the flag's own key, so the same user gets an independent-looking assignment for every different flag. 3. It runs the pair through a fast, well-distributed hash function. 4. That hash is mapped onto a fixed numeric range, commonly 0-99 or a finer 0-99999 for more precision at low percentages, producing what's usually called the user's **bucket** for that flag. Enabling the flag for 10% of users then just means: if bucket is under 10 (or under 10000 out of 100000), evaluate to true. Because hashing a given flag-key-and-user-id pair always produces the same bucket number, the same user gets the same answer every single time they're evaluated, on any server, in any request -- that's what **sticky bucketing** means. ## Why stickiness is the whole point Stickiness is not a nice-to-have; it's the entire point. Two properties fall out of it that would otherwise be impossible. 1. **First, consistency within a user's experience.** If the flag gates a multi-step flow such as a new checkout form, the user needs to see the same variant on step one and step five, or the flow breaks or looks buggy; a re-randomized-per-request assignment would flicker the user between old and new UI on every page load. 2. **Second, monotonic growth -- just as important operationally.** Because the bucket number for a user never changes, raising the rollout threshold from 10% to 20% is guaranteed to be a superset -- every user already in at 10% stays in, and only new users are added -- rather than reshuffling the entire population. That monotonic property is exactly what a staged canary rollout depends on: engineers watch error rates and latency at 1%, then 5%, then 25%, then 100%, confident that the users already exposed keep being exposed and the blast radius only grows in one direction. ## Why the pattern exists: risk control The reason this pattern exists at all is risk control during release. Flipping a flag to 100% for every user simultaneously means any bug, performance regression, or unexpected load pattern hits your whole user base at once, with no early warning. A percentage or canary rollout turns a release into a controlled experiment against production traffic: start small, watch dashboards and alerts, and only widen exposure once the smaller cohort looks healthy. It's worth distinguishing this flag-level canary from an infrastructure-level canary deployment -- the latter is about validating the new build itself. | Flag-based percentage rollout | Infrastructure-level canary deployment | |---|---| | A flag-based rollout instead varies behavior within a single, already-deployed binary | Routes a small percentage of traffic to a new binary or version running on a subset of instances | | Based on which users are bucketed in | Independent of any user identity | The two are complementary and often layered: you might canary a new binary to 5% of instances first, and separately, within that binary, still gate the risky feature behind its own flag rollout percentage. ## The trade-offs The trade-offs run in both directions. - Sticky bucketing gives consistency and monotonic rollout, but it means you cannot cleanly do a targeted, per-user rollback: if one specific unlucky user in the 10% cohort is hitting a bug, you can't surgically exclude just them without a separate explicit exclusion rule layered on top; the only blunt instrument is rolling the whole percentage back, which removes everyone. - At low percentages, hashing also introduces statistical noise. 1% of a million users is a solid sample, but 1% of ten thousand users is a much noisier signal, so error-rate comparisons between in and out cohorts need enough absolute users to be meaningful. ## Failure modes The characteristic failure modes are worth naming concretely. 1. If the identifier used for hashing isn't actually stable -- for example bucketing by a request-scoped correlation ID for a user who is sometimes anonymous and sometimes logged in -- the same human gets reshuffled into a different bucket on every visit, silently defeating stickiness and reproducing the flicker problem described above. 2. Another common failure is when client-side and server-side SDKs for the same flag platform implement the hash differently or seed it differently, so a mobile app and a backend service disagree about which bucket a given user is in, producing an inconsistent cross-surface experience. 3. A third is forgetting to segment monitoring by bucket during a canary: if error-rate dashboards aggregate all traffic together, a real regression hiding inside the 5% in cohort gets diluted into noise by the 95% unaffected cohort and never trips an alert. ## Where it shows up in the wild A concrete real-world instance: LaunchDarkly's percentage rollout implementation is exactly this deterministic-hash-into-bucket model, and it explicitly documents that rollouts are sticky per user and that raising a rollout percentage only adds users, never reassigns existing ones -- precisely so staged canary releases behave the way on-call engineers expect when they widen exposure step by step while watching dashboards.