All rate limiting plugins support some subset of the following strategies:
Strategy | Pros | Cons | Supported in plugin |
---|---|---|---|
local |
Minimal performance impact. | Less accurate. Unless there’s a consistent-hashing load balancer in front of Kong, it diverges when scaling the number of nodes. | AI Rate Limiting Advanced Rate Limiting Advanced Rate Limiting Response Ratelimiting |
cluster |
Accurate1, no extra components to support. | Each request forces a read and a write on the data store. Therefore, relatively, the biggest performance impact. | AI Rate Limiting Advanced Rate Limiting Advanced Rate Limiting Response Ratelimiting GraphQL Rate Limiting Advanced |
redis |
Accurate1, less performance impact than a cluster policy. |
Needs a Redis installation. Bigger performance impact than a local policy. |
AI Rate Limiting Advanced Rate Limiting Advanced Rate Limiting Response Ratelimiting GraphQL Rate Limiting Advanced |
[1]: Only when
sync_rate
option is set to0
(synchronous behavior). See the configuration reference for each plugin for more details.
Two common use cases are:
- Every transaction counts. The highest level of accuracy is needed. An example is a transaction with financial consequences.
- Backend protection. Accuracy is not as relevant. The requirement is only to protect backend services from overloading that’s caused either by specific users or by attacks.