Setting up Spike Arrest and Quota policy -multiple message processers

Not applicable

Scenario

We have 4 message processors in our Infrastructure.

And for one API,we have two consumers.The scenario is ,One consumer says 100TPS and another says 30 TPS.

Design

I am going to have quota policy with dynamic quota setup by having custom attribute in Developer application for quota limit.

So,one consumer app will have custom attribute as 100 * 60 TPM and another as 30 * 60 TPM and that attribute is going to be referred for Allow countRef.

And I will setup Distributed quota.Hope I am correct with my design so far to achieve this scenario.

Question

However I am not sure what I need to set for Spike arrest.

Should I set (100 TPS +30 TPS)/4 MPs ~ 33 TPS in spike arrest policy ,since Spike arrest is not distributed among 4 MPs? And I will not be setting the Identifier in Spike Arrest.

Or should I follow some other strategy based upon how much backend can support maximum?For eg:if backend says 1200TPS,then we can set 1200/4 = 300 TPS in Spike Arrest?

0 5 207
5 REPLIES 5

Not applicable
@Apigee Support

Please provide an update on this question...

Any reason you wouldn't use API products to control the different quotas instead of setting attributes on the apps themselves? I think that would be a cleaner solution and would be easier to maintain.

Your second strategy for Spike Arrest makes more sense. Since the backend supports max 1200 tps, set the spike arrest for that, regardless of consuming application.

@Carlos Eberhardt Thanks for your response. If I use API products ,then I would have to create multiple API products for the same proxy to set just the quota limit so that different consumer application can consume it differently. As I already have applications for each consumer,if I set the quota limit in the application level using custom attribute,I can refer the same in my proxy policy. Please correct me if I am not thinking in the right direction.

All depends on how you expect to manage it and what change looks like. If you don't have multiple apps that will use the same quota values and are ok with managing changes at the app level, that's just fine. I was thinking of a situation where you'd have, say, three different quota ranges and dozens of apps. Then managing at the product level is easier and less prone to error over time, in my opinion.

Thankyou @Carlos Eberhardt .This helps..