I want to throw an error when anomaly mitigation is enabled and the algorithm is not weighted_random, so I added a '!' before isWeightedRandomAlgorithm.

The codechanges make sense to me but the only thing I'm not so keen on is enforcing the restrictions on the properties:

• weighted_random algorithm cannot be used in slow start mode
• anomaly mitigation can only be enabled when the weighted_random algorithm is used

with error handling in the constructor. For this current case it works fine because we're not adding much but this can slowly grow over time into a wall of error handling checks as more properties with restrictions are added.

What I had in mind here was to instead create another version of this class that specifically has the weighted_random algorithm set by default and does not allow the user to set other conflicting properties to remove the need for these error checks.

i.e. A class like ApplicationTargetGroupWeightedRandomRouting or something where the anomaly mitigation can be enabled or not without the need for error handling and slow start mode is disabled and cannot be enabled.

Although part of me worries that this may be a bit confusing as a DX to use because we're not providing the option through ApplicationTargetGroup and I'm not sure how many other routing algorithm options there are that we may not have done this for. What do you think?

Thank you for your suggestion.

Personally, I like the current consolidated form of ApplicationTargetGroup.

• While there are other routing algorithms such as Least outstanding requests, I think having only weighted random as a separate class would be confusing for users.
• Additionally, I think that the current restriction is not complex enough to warrant a separate class.
• There are common items with other routing algorithms such as stickiness.enabled, and it's easier to understand when they are grouped together.

For the reasons mentioned above, I personally think the current format is preferable.
However, as you've expressed concern, your suggestion might be better considering the possibility of increased constraints in the future.
But honestly, I'm not sure if they will increase...

Given the above, I'd appreciate your thoughts on this.

Thanks for sharing your thoughts.

After hearing your reasonings I agree that separating out a new class just for this algorithm is probably not necessary. As you mentioned, the restriction is not super complex so I'm okay to accept this change as is.

Thanks @mazyu36!

Can we also document the. restriction that the weighted_random algorithm cannot be used with slow start mode?

Thanks. I've updated docs.

The codechanges make sense to me but the only thing I'm not so keen on is enforcing the restrictions on the properties:

• weighted_random algorithm cannot be used in slow start mode
• anomaly mitigation can only be enabled when the weighted_random algorithm is used

with error handling in the constructor. For this current case it works fine because we're not adding much but this can slowly grow over time into a wall of error handling checks as more properties with restrictions are added.

What I had in mind here was to instead create another version of this class that specifically has the weighted_random algorithm set by default and does not allow the user to set other conflicting properties to remove the need for these error checks.

i.e. A class like ApplicationTargetGroupWeightedRandomRouting or something where the anomaly mitigation can be enabled or not without the need for error handling and slow start mode is disabled and cannot be enabled.

Although part of me worries that this may be a bit confusing as a DX to use because we're not providing the option through ApplicationTargetGroup and I'm not sure how many other routing algorithm options there are that we may not have done this for. What do you think?