API Rate Limit Calculator
Calculate optimal rate limits for your API: a per-client limit and burst sized for your peak, with ready-to-paste Nginx, Kong and AWS configurations.
Your traffic
Strategy & burstBurstToken bucket · burst auto
Leave burst empty for 20% of the per-client limit (at least 1).
Per-client limit
18req/s
Burst 4 per client. Covers your 150 req/s peak with 20% headroom.
+30 req/s headroom over your peak
- Global cap (all clients)
- 180 req/s
- Global burst
- 40 req
- Per client / minute
- 1,080
# Nginx rate limiting — inside the http {} block
# Per client: 18r/s (keyed by client IP; use e.g. $http_x_api_key to key by API key)
limit_req_zone $binary_remote_addr zone=per_client:10m rate=18r/s;
# Whole API: 180r/s across all clients
limit_req_zone $server_name zone=api_global:1m rate=180r/s;
server {
listen 80;
server_name api.example.com; # the global zone is keyed on this
location /api/ {
limit_req zone=per_client burst=4 nodelay;
limit_req zone=api_global burst=40 nodelay;
limit_req_status 429;
# Nginx has no built-in "remaining"/"reset" variables; send the limit only.
add_header X-RateLimit-Limit 18/s always;
}
}Rates and queueAverage 100 req/s · Token bucket
- Average / second
- 100
- Average / minute
- 6,000
- Average / hour
- 360,000
- Per client / minute
- 1,080
- Global cap / minute
- 10,800
- Queue size (token bucket)
- 4
How the limit is worked outmax(average, peak) × 1.2 ÷ clients
- Global cap = max(average, peak) × 1.2 = 180 req/s, so legitimate peak traffic is never throttled.
- Per-client limit = global cap ÷ 10 clients = 18 req/s.
- Burst = 20% of the per-client limit, at least 1 = 4 requests per client (40 across all clients).
- The snippets limit each client to the per-client rate and cap the whole API at the global rate. Nginx needs whole r/s or r/m, so rates are rounded up.
How this works: Method, 2 sources,
How this works
Method
The global cap is the higher of your average rate (converted to requests per second) and your peak, plus 20% headroom, and the per-client limit is that cap divided by the number of clients. Burst per client is your value or 20% of the per-client limit (at least 1 request); the Nginx, Kong and AWS snippets round rates up to the whole units each one accepts.
Sources
- RFC 6585, Additional HTTP Status Codes (429 Too Many Requests) (IETF)
- RateLimit header fields for HTTP (draft-ietf-httpapi-ratelimit-headers) (IETF)
Changes
- Redesigned with a ruler of your average, peak and cap split across clients; the limit is now sized from your peak plus 20% headroom, and the snippets set both a per-client and a whole-API limit.
- Corrected the headers note: X-RateLimit-* is a common convention, not a standard; RFC 6585 defines only the 429 status and Retry-After.
- Results now update as you type, starting from a filled-in example.
- First published.
Frequently Asked Questions
What is rate limiting and why is it important?
Rate limiting controls how many requests a client can make to your API within a time window. It prevents abuse, protects your infrastructure from overload, ensures fair usage, and maintains service quality for all users. Without rate limiting, a single client could overwhelm your API and affect other users.
Which rate limiting strategy should I use?
Choose based on your needs: Token Bucket (most flexible, allows bursts), Fixed Window (simple, predictable), Sliding Window (accurate, no edge cases), or Leaky Bucket (smooth, constant rate). For most APIs, Token Bucket is recommended as it allows flexibility while preventing abuse.
How do I calculate the right rate limit for my API?
Start with your infrastructure capacity: determine how many requests your servers can handle, then divide by the number of concurrent consumers. Add a safety margin (20-30%) for peak traffic. Monitor your metrics and adjust based on actual usage patterns. Consider tiered limits: free tier, basic tier, premium tier.
What are burst requests and why do they matter?
Burst requests are short-lived spikes in traffic that briefly exceed your average rate. They matter because they can overwhelm your system even when the average rate looks low. A good rate limiter allows some burst capacity (typically 10-20% above the average) to absorb legitimate traffic spikes while still protecting your infrastructure from sustained overload.
How do I configure rate limiting for Nginx?
In Nginx, use the limit_req zone. Example: limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s; Then apply it: limit_req zone=mylimit burst=20 nodelay; The burst parameter allows temporary spikes, and nodelay processes them immediately rather than queuing.
What headers should I return for rate limiting?
The X-RateLimit-* family (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) is a widely-used de-facto convention rather than an official standard — RFC 6585 only defines the HTTP 429 status and the Retry-After header. A separate IETF draft proposes standardized RateLimit-Limit / RateLimit-Remaining / RateLimit-Reset fields, which some APIs are starting to adopt.