Rate limiting is used to control the rate of traffic sent to or received by an API. Traffic that is less than or equal to the specified rate is sent, whereas traffic that exceeds the rate is rejected. There are business and technical reasons to control the traffic an API receives. Rate limiting can be implemented with either quotas or SpikeArrests on the request path in a flow:
- Quotas limit the number of API calls your application makes, ensuring that every developer consumes a proportionate amount of API resources for business reason.
- SpikeArrests stop traffic spikes (or bursts) that can be caused by an increase in usage, buggy clients, or malicious attacks.
About SpikeArrests
You can use SpikeArresting to keep your API operational and manage traffic when you have spikes due to increased usage.
A SpikeArrest limits the number of requests sent to either the client or target endpoints. SpikeArrest-based rate limiting supports short intervals such as seconds and minutes. A SpikeArrest configuration allows messages to pass at a steady rate. Any instantaneous bursts are suppressed.
For example, if you define the rate as 100 messages per second, it translates to approximately 1 message every 10 milliseconds. A SpikeArrest works well provided you specify the number of messages in granularity of seconds, which means >= 60 messages per minute or >= 1 message per second.
Configuring a SpikeArrest policy
Configure your SpikeArrest policy using the following elements.
| Field Name | Description |
|---|---|
| Rate or peak message rate (Mandatory) | Specifies the rate at which to limit the traffic spike (or burst). Valid value: integer per <min> or <sec>. |
| Identifier or client identifier (Optional) | Variable used for uniquely identifying the client. |
| Message weight (Optional) | Specifies the weighting defined for each message. Message weight is used to increase the message weighting, which is the amount of resources needed to process the message. Message weight can be extracted from headers/query parameters/message body. For example, if the limit is 10 messages/min and the weight is 2, then it can allow only 5 messages for processing (10/2). The rate limit is violated starting with the sixth message. |
Policy schema
Each policy must conform to a policy schema. All policy constructs such as elements and attributes mentioned above are defined in a schema. To download the schema, click here.
Examples - SpikeArrests
5 per second
<SpikeArrest name="SpikeArrest"> <Rate>5ps</Rate> </SpikeArrest>
12 per minute
<SpikeArrest name="SpikeArrest"> <Rate>12pm</Rate> </SpikeArrest>
12 per minute with message weight reference
<SpikeArrest name="SpikeArrest"> <Rate>12pm</Rate> <Identifier ref="request.header.ID" /> <MessageWeight ref="request.header.weight" /> </SpikeArrest>
SpikeArrest flow variables
Flow variables play a pivotal role in message flow. These variables enable advanced users to customize the behavior of policies and flows, based on the headers or message content, or the context available in the flow. The following predefined flow variables are accessed in SpikeArrest alert messages. For more information about flow variables, see Variables reference.
| Variable | Type | Permission | Description |
|---|---|---|---|
| ratelimit.<policy-name>.allowed.count | Long | Read-Only | Returns the allowed limit count |
| ratelimit.<policy-name>.used.count | Long | Read-Only | Returns the limit used in the counter |
| ratelimit.<policy-name>.exceed.count | Long | Read-Only | Returns the count exceeds the limit in the current counter |
| ratelimit.<policy-name>.expiry.time | Long | Read-Only | Returns the time in milliseconds based on which the limit expires and new counter starts |
