Spike arrest in Apigee

The Spike Arrest policy protects against traffic surges with the <Rate> element. This element controls the number of requests processed by an API proxy and sent to a backend, protecting against performance lags and downtime.

This policy smooths traffic spikes by dividing a limit that you define into smaller intervals. For example, if you define a limit of 100 messages per second, the SpikeArrest policy enforces a limit of about 1 request every 10 milliseconds (1000 / 100); and 30 messages per minute is smoothed into about 1 request every 2 seconds (60 / 30). The SpikeArrest limit should be close to capacity calculated for either your backend service or the API proxy itself. The limit should also be configured for shorter time intervals, such as seconds or minutes. This policy should be used to prevent sudden traffic bursts caused by malicious attackers attempting to disrupt a service using a denial-of-service (DOS) attack or by buggy client applications.

The <SpikeArrest> element uses the following syntax:

This element has the following attributes that are common to all policies:

name 

      is the internal name of the policy. The value of the name attribute can contain letters, numbers, spaces, hyphens, underscores, and periods. This value cannot exceed 255 characters.

Optionally, use the <DisplayName> element to label the policy in the management UI proxy editor with a different, natural-language name.

continueOnError 

Set to "false" to return an error when a policy fails. This is expected behavior for most policies. Set to "true" to have flow execution continue even after a policy fails.

enabled 

Set to "true" to enforce the policy. Set to "false" to "turn off" the policy. The policy will not be enforced even if it remains attached to a flow.

The following element that are common to all policies:

DisplayName

Use in addition to the name attribute to label the policy in the management UI proxy editor with a different, more natural-sounding name.

Identifier

Lets you choose how to group the requests so that the Spike Arrest policy can be applied based on the client. For example, you can group requests by developer ID, in which case each developer's requests will count towards their own Spike Arrest rate and not all requests to the proxy.

Message Weight

Specifies the weighting defined for each message. Message weight modifies the impact of a single request on the calculation of the Spike Arrest rate. Message weight can be any flow variable, such as an HTTP header, query parameter, form parameter, or message body content. You can also use custom variables using the JavaScript policy or the Assign Message policy.

Rate

Specifies the rate at which to limit traffic spikes (or bursts) by setting the number of requests that are allowed in per minute or per second intervals. You can also use this element in conjunction with <Identifier> and <MessageWeight> to smoothly throttle traffic at runtime by accepting values from the client.

UseEffectiveCount

Distributes your Spike Arrest counts across Message Processors (MPs) when using auto-scaling groups.

The effect of <UseEffectiveCount> depends on it's value:

    true: An MP's spike rate limit is the <Rate> divided by the current number of MPs in the same pod. The aggregate limit is the value of <Rate>. When MPs are dynamically added (or removed), their individual spike rate limits will increase (or decrease), but the aggregate limit will stay the same.

   false (this is the default value if omitted): Each MP's spike rate limit is simply the value of its <Rate>. The aggregate limit is the sum of the rates of all the MPs. When MPs are added (or removed), their individual spike rate limits will stay the same, but the aggregate limit will increase (or decrease).

This element has the following attributes that are common to all policies: in which you can use the Spike Arrest policy: