undefined | Better HN

0 pointssimonw1y ago0 comments

I've worked at places where the feature flag system was much more dynamic than that, considering way more than just membership in a group.

This meant you could roll features out to:

- Specific user IDs

- Every user ID in a specific group

- Every object owned by a specific user ID (feature flags might apply to nested objects in the system)

- Requests from IP addresses in certain countries

- Requests served by specific website TLDs

- Users who are paid members of a specific plan

- etc etc etc

It was an enormously complicated system, that had evolved over 5-10 years.

Not saying that level of complexity is recommended, but that's what we had.

Looks like I gave a talk about this back in 2014: https://speakerdeck.com/simon/feature-flags

0 comments

> This meant you could roll features out to:

That's how feature flag services work.

The whole point is that this is not a querying problem. That's a group assignment problem.

Users/sessions are assigned to a feature group according to business rules. These can be as complex as anyone wants them to be.

Once a user/session is assigned to a feature group, the problem of getting features is a key-value query.

j / k navigate · click thread line to collapse