APIGEE Spike Arrest Best practise / Pragmatic usage for Front End Integration

Question

Was dealing with the APIGEE gateway development recently and found out that the usage of Spike Arrest is very limiting to certain integrations (Backend only). As per recommended by APIGEE, we should avoid the usage of concurrent rate limit here and potentially replaced it with spike arrest.

But the way how Spike Arrest is implemented is kinda dodgy, Eg spike arrest of 10 tps indicates that it will return trigger spike arrest limit exception when it receives more than 1 request per 100ms.

With such behaviour, it looks like the rate control has to be control at the client side. It is definitely possible to do it from the client backend, but what about those APIs which are used directly from the Front End?

Would like to understand what is the recommended identifier for a Spike Arrest under different scenarios

Backend Integration

• Probably by per client id via API key or auth token

Front End / SPA

A hard one, as unlike backend it is impossible to control request rate from the browser considering multiple user multiple tab, however, I have considered

• IP? (but single IP != single user session)
• Browser SessionId?
• Rest client to be spike arrest error aware and to perform a retry?
• Should not use spike arrest?

Any insights are welcome and appreciated

Answer 1

I believe you are thinking correctly about this space. Useful quick reference: https://docs.apigee.com/api-platform/develop/comparing-quota-spike-arrest-and-concurrent-rate-limit-policies As you noted the ConcurrentRateLimit policy is deprecated, but between Quota policy (by call allotment) and SpikeArrest (controlled by rate) you can easily control load to your services. Both policies allow you to specify an attribute in order to maintain separate counters or rate calculations based on the value you set for the attribute. This gives you many options for your front-end use case, which may be better served by a quota or a plain rate. I think of rates as more raw protection, and quotas to be more product-management governed in type, but either (or both) can work. Consider a Quota policy based on SessionID and a safety-net SpikeArrest policy set very high as a second layer of protection against overloading your services. In any case though, yes, your clients should be HTTP-429-aware and know how to retry.