Token Bucket Algorithm
The Rate Limit Plugin uses a token bucket algorithm:
Bucket Size:burst_capacity tokens
Refill Rate:requests_per_second tokens per second
Request Cost: 1 token per request
Behavior: Allows bursts up to bucket size, then sustained rate
Response Headers
The Rate Limit Plugin adds these headers to responses:
Header
Description
Example
X-RateLimit-Limit
Requests per second limit
10
X-RateLimit-Remaining
Tokens remaining in bucket
7
X-RateLimit-Reset
Unix timestamp when bucket refills
1657464945
Retry-After
Seconds to wait (on 429 responses)
10
Rate Limited Response
HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 10
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1657464955
Retry-After: 10
Content-Type: application/json
{
"error": "Rate limit exceeded",
"message": "Too many requests. Please try again later.",
"retry_after": 10
}
Schema Inheritance
This schema inherits from the UtilityPlugin schema, which provides:
logfile - Log file path
directory - Directory configuration
enabled - Plugin enable/disable state
And ultimately from the base Plugin schema, which provides:
library - Plugin library path
plugin - Base plugin reference property
Configuration Recommendations
Common Rate Limiting Scenarios
Scenario
RPS
Burst
Strategy
Rationale
Public API
1-5
10-15
ip
Prevent abuse while allowing normal usage
Authenticated API
10-50
100-150
user
Fair usage per authenticated user
Upload Endpoints
0.1-0.5
2-5
user
Expensive operations need strict limits
Health Checks
No limit
-
-
Exclude from rate limiting
Server Protection
1000
2000
global
Overall server capacity protection
Validation Rules
requests_per_second must be a positive number (supports decimals)
burst_capacity must be greater than or equal to requests_per_second
key_strategy must be one of: "ip", "user", "global"
cleanup_interval must be a positive integer (seconds)
For "user" strategy, authentication must be configured before rate limiting
The name property should be unique if multiple rate limit plugins are used
Plugin Pipeline Placement
The Rate Limit Plugin should be placed early in the plugin pipeline, typically before expensive operations but after any authentication plugins if using "user" strategy. This prevents abuse while ensuring proper user identification.