Add action to support modulo condition evaluations within feature flag utility.
Motivation
Why are we doing this? What use cases does it support? What is the expected outcome?
Feature flags are instrumental in experimentation. An important aspect of product experimentation is to allow the feature to be visible to a subset of the users spectrum. This is done in most experiments using the modulo operator on an identifier. To experiment with 20% of the users, the feature flag should be enabled for say - 0 <= user_id % 100 <= 19. A parallel experiment could run for - 20 <= user_id % 100 <= 39
Proposal
This is the bulk of the RFC.
Explain the design in enough detail for somebody familiar with Powertools to understand it, and for somebody familiar with the implementation to implement it.
The modulo operator is a standard mathematical operator easy to implement and has varied use-cases in experimentation.
Add a new action to support modulo evaluation in the feature flag utility.
The action configuration will have the following value, where the expressions a is the key and b is the value above:
Action
Equivalent expression
MODULO_RANGE
lambda a, b: b.start <= a % b.base <= b.end
If this feature should be available in other runtimes (e.g. Java), how would this look like to ensure consistency?
Feature utility is only available in Python. If we wish to extend this functionality to other runtimes, there should be no problem as there is no language dependency for this feature.
User Experience
How would customers use it?
Users will be able to customise their experiments to user spectrums and have visibility over running parallel and orthogonal experiments within their product.
Any configuration or corner cases you'd expect?
None
Demonstration of before and after on how the experience will be better
This is a new feature, it will expand the applicability of this utility to support more user needs as mentioned above.
Drawbacks
Why should we not do this?
Do we need additional dependencies? Impact performance/package size?
None
Rationale and alternatives
What other designs have been considered? Why not them?
considered having a constant base of 100
a variable base allows for more custom experimentation basis the user's spectrum size
considered a list of values for [0, 19] instead of two variables for start and end
a list could imply more values could be appended and comprehension of rules becomes difficult. With two variables, the readability improves considerably
What is the impact of not doing this?
incomplete set of conditions for a feature flag utility.
Unresolved questions
Optional, stash area for topics that need further development e.g. TBD
Key information
Summary
Add action to support modulo condition evaluations within feature flag utility.
Motivation
Feature flags are instrumental in experimentation. An important aspect of product experimentation is to allow the feature to be visible to a subset of the users spectrum. This is done in most experiments using the
modulo
operator on an identifier. To experiment with 20% of the users, the feature flag should be enabled for say -0 <= user_id % 100 <= 19
. A parallel experiment could run for -20 <= user_id % 100 <= 39
Proposal
The modulo operator is a standard mathematical operator easy to implement and has varied use-cases in experimentation.
Add a new action to support modulo evaluation in the feature flag utility.
lambda a, b: b.start <= a % b.base <= b.end
If this feature should be available in other runtimes (e.g. Java), how would this look like to ensure consistency? Feature utility is only available in Python. If we wish to extend this functionality to other runtimes, there should be no problem as there is no language dependency for this feature.
User Experience
How would customers use it? Users will be able to customise their experiments to user spectrums and have visibility over running parallel and orthogonal experiments within their product.
Any configuration or corner cases you'd expect? None
Demonstration of before and after on how the experience will be better This is a new feature, it will expand the applicability of this utility to support more user needs as mentioned above.
Drawbacks
Rationale and alternatives
[0, 19]
instead of two variables for start and endUnresolved questions