Spike Arrest Tip

[#1]

Spike arrest policy, as the name suggest, is used to control the high incoming load of requests to prevent back-end meltdown.

When you implement spike arrest policy, it is best to add it as early as possible in the request flow. If it can be first and foremost policy - nothing like it!

A lot of production scenarios which I have noticed - spike arrest is way down the line -after authentication, request parsing etc. When the spike is hit - all the work done priror to it is wasted.

This of course prevents back-end meltdown, however the proxy servers keep handling the load and do wasteful stuff before they are instructed to throw away the request. This can also affect other valid request processing in proxies. Even though, Apigee handles this scale - why give wasteful work if you know you can eliminate it.

Think about the following approach to Spike Arrest policy, with the assumption that you are under high load of request

1. If it is a blind arrest, then make it the first policy.
2. If it is based on request param, still it can be first policy with the request param used. No need to parse request completely.
3. Do you really need authentication? - not sure if this valid in most cases. It will be interesting to know scenarios where authentication is needed to arrest load.
At times spike arrest parameter is pulled out of KVM.

• In such cases, i think it better have the value pulled of KVM into a non-distributed cache. Use the value from the cache to handle spike.
• The cache in this case is local in-memory and non-distributed(no L2) - extremely fast under high load.
• Please note, KVM is optimized to use caches - both distributed and non-distributed for its working.
• But, personally i prefer non-distributed exclusive cache - when i am expected to deal with high load.

It will be interesting to know what you guys think?

[sarthak]

@sriki77

In majority of the scenarios which I have seen, even if spike is hit the API provider needs to know which all of their API consumers are impacted. Hence authN/authZ will be required, probably a message logging, analytics etc. Hence all those policies need to be executed before.

What if the data is cached ? Though the backend can handle 1000 calls per minute , it can be 5000 calls can be served from the cache itself. So Spike arrest should be after the cache.

I would ideally like to attach the spike arrest on the target side.

I would place it before transformation type of policies but probably not before the others described above. I have not met a customer who does not want to know which all apps or api consumers are getting the errors because of hitting spike arresting.