| I've implemented a similar service in our company inspired from this project. There are few of differences though: - we are using redis instead of leveldb. This way we can scale the service to multiple instances - created an API to get all feature flags for an user which is also rendered to the client, so there are no unnecessary requsts to APIs not available - next on the list there will be caching on the service side and syncronization using redis pub/sub - currenty we are keeping the user ids explicitly enabled for a feature inside the feature array, but we are going to store them in a more efficient way. For example, if we are going to launch the v2 dashboard view, users should be able to opt-in for beta access. Storing half of your user ids in a leveldb/redis array and iterating each time over it is not efficient. - Changed user ids from integer to strings. We are using uuids, but everybody should be able to hash the integer user id to an efficient string randomized represantation (hmac, sha1, md5). - Using a hashing function to represent user ids on a scale between 1 and 100 is not efficient. What happens if you allow 5% traffic and only users with hash > 10 are using your site ? Hashing user id to a 1..100 key always yields the same result. Users having hash key 1 will always see the new features and bugs. Not a nice thing.
We are going to implement a more efficient way: first time a user is checked for a feature we put him in a bucket (there are 100 buckets). First user in bucket 1, second in bucket 2, etc. This way, usage gets randomized for each user on each feature, and inactive users will not have the feature enabled by default |