[Design Doc] Feature flag backend V2

[vikhyat187]

The features which we have planned in V2 are

1. Enable feature flag for a group of users
2. Enable feature flag for X% of users

---

1. Enable feature flag for a group of users

Approach 1:

• For this requirement we can store the user roles in a new column userRoles in FeatureFlagUserMapping table, but this will lead to inconsistency when the user roles gets updated, it also needs to be updated in FeatureFlagUserMapping table.
• Have a new table for UserRolesFeatureFlagMapping which has the combination of roles to flagIds with status.
• Here we pass the user roles from the calling service.
• The amount of data transfer via the network increases in this approach. (We are transmitting the user roles and this data can increase over time).

Approach 2:

• In this we don't store the roles in feature flag DDB tables and fetch them from the firebase User tables, so here we will have the user roles consistent, as we have single data source.
• Any update on roles will be updated in Users table.
• We can do this by querying the user data from the userId which is passed from the consumer service.
• We need to think of caching on User's API which fetches details by userId
• Two ways which we can have is directly talking to firestore or querying using website-backend
• In case of querying using website-backend, if the feature flag's user roles API throughput increases website backend's users userId API throughput also increases, which isn't the right way.

[shubham-y]

• when the user roles gets updated

I think we should first define what we mean by roles here
If by roles, we mean only member, super_user, and admin roles then the number of times the user roles get updated is not that frequent.

• (We are transmitting the user roles and this data can increase over time).

I am not sure I understand this. How will the data increase over time?

• I think whichever approach we take, we will have to store the mapping of flagId to user roles. For example, in approach 2 when a request comes in to check if the feature flag is enabled for a userId then without storing the information of roles and flag Id mapping we won't be able to give a result.

• We also need to think about which will have more priority in case of a difference where the feature flag is enabled for a userId but its disabled for the role of the same user or vice versa.
  Consider a scenario, that a developer with role=user working on a feature that will only roll out to role=members users need to also get access to the feature for testing. I think to handle such scenarios we will have to query both the tables of flagId, userId mapping & flagId, roles mapping (assuming we store them in separate tables) and in the case of approach 2 we will also be querying the Firestore tale to get the users role.