> I believe he means doing a rollout to 30% of users and having that be consistent

Exactly. Also, not only shall the evaluation be consistent for a specific percentage and userId, but also, when increasing the percentage, an enabled feature shall never be retracted for a user which had the feature enabled before.

userId could also be IPs, country codes, worker nodes etc etc.

Would you mind slightly elucidating on that algorithm? Max.Integer would be 2^32-1 for instance? Where does the 30% parameter get exercised?

I thought it was the traditional circle point consistent hashing algo that GP was discussing but this is interesting.

Sure. https://github.com/prefab-cloud/prefab-cloud-java/blob/main/... is consistent function that turns a string into a float in the range 0-1.

So if you hash "flagA-user1234" you'll get a number 0-1 and if you compare that to < .3 you'll know whether they should be "in the flag".

Relies on the uniformity of the hashing function.

Oh of course. Very reasonable. Thank you for source code link. I think I understand now.

yeah, "an enabled feature shall never be retracted for a user which had the feature enabled before" is extra spicy and requires a different architecture entirely, since you fundamentally need to store the evaluation for each user and check before you return a value.

Definitely something to use with caution in my experience, since the performance profile is very different.

IMHO it's fine if the feature is retracted for a minimal number of users when scaling down (can be done stateless, as described in your other post). It's just that it shouldn't jiggle all over the place when gradually increasing the percentage.