API Rate Limit & Throughput Calculator — RPS, Bandwidth & Burst

How Rate Limit Calculator Works

RPS = RPM / 60 Bandwidth = RPS × Payload Size Daily Capacity = RPM × 60 × 24 Per-User RPM = RPM / Peak Users

Rate limiting controls how many requests a client can make to an API within a given time window. Understanding your throughput helps you plan capacity and avoid 429 (Too Many Requests) errors.

RPM

Requests Per Minute — The maximum number of API requests allowed per minute.

RPS

Requests Per Second — Throughput in requests per second — the steady-state rate your API serves.

Burst

Burst Capacity — The maximum short-term throughput your API can handle before rate limiting kicks in.

429

HTTP 429 Too Many Requests — The HTTP status code returned when a client exceeds the rate limit.

How to Use

1. Enter your API's maximum requests per minute (RPM).
2. Enter the average payload size in KB to calculate bandwidth requirements.
3. Optionally enter peak concurrent users to see per-user allocation.
4. Select your server type to see burst capacity defaults.
5. Use the results to plan infrastructure scaling and set appropriate rate limits.

Quick Reference

Common Uses

• •Planning API infrastructure capacity by calculating requests per second, bandwidth requirements, and daily throughput
• •Setting appropriate rate limits for public APIs to protect backend services from abuse and unexpected traffic spikes
• •Determining burst capacity and per-user rate limits when designing API pricing tiers or usage plans
• •Estimating bandwidth costs and infrastructure needs for high-traffic web applications and microservices deployments

Understanding the Result

Rate limiting is a critical API management strategy that protects your backend from being overwhelmed by too many requests. When a client exceeds the allowed rate, the server returns HTTP 429 (Too Many Requests). The difference between burst and steady-state capacity is key: burst allows short spikes above the sustained limit, while the sustained rate is what your infrastructure can handle long-term. AWS API Gateway has a default burst limit of 10,000 RPM. Cloudflare offers effectively unlimited burst. Nginx burst depends on worker configurations. For production APIs, set rate limits at 2-3x your expected peak traffic to handle spikes while protecting your backend.

Worked Examples

Frequently Asked Questions

What happens when a user exceeds the rate limit?

The server returns HTTP 429 (Too Many Requests) with a Retry-After header indicating how long the client should wait before retrying. Well-designed clients should implement exponential backoff.

What is the difference between burst and sustained rate limits?

Burst allows short-term spikes above the sustained limit (e.g., 10,000 RPM burst on a 1,000 RPM sustained limit). Sustained is the average rate your system can handle over longer periods.

What is a reasonable rate limit for my API?

A common approach is to set the rate limit at 2-3x your expected peak traffic. For a public API, 1000-10000 RPM per user is typical. Adjust based on your infrastructure and user base.

How should clients handle 429 errors?

Clients should implement exponential backoff: wait 1 second on first retry, 2 seconds on second, 4 seconds on third, etc., up to a maximum. This prevents thundering herd problems.

Which rate-limiting algorithm should I use?

The token bucket algorithm (used by AWS and most API gateways) is ideal for most APIs — it allows short bursts while enforcing a long-term average rate. The leaky bucket smooths traffic to a fixed rate (better for bandwidth shaping). The fixed window counter is simplest but can allow double the rate at window boundaries. Sliding window log provides the most accurate enforcement at the cost of more memory.

Pro Tips

• →Set your API rate limit at 2–3× expected peak traffic, not at your infrastructure's breaking point. This gives you headroom for organic growth and unexpected traffic while still protecting the backend. A limit that is exactly at peak means your users will hit 429s during normal usage.
• →Always pair rate-limited APIs with exponential-backoff client libraries. A well-behaved client that retries with 1s → 2s → 4s → 8s delays can reduce perceived downtime from seconds to unnoticeable milliseconds. Return the `Retry-After` header to guide client behavior.
• →Per-user RPM allocation is a critical metric for API pricing tiers. If your per-user RPM drops below 10, interactive use (e.g., a dashboard polling an endpoint) becomes sluggish. Aim for 30–60 RPM/user for a responsive experience, and 10+ RPM/user for background/batch operations.
• →Bandwidth costs scale with payload size, not request count. If your 50 KB responses are at 1,000 RPS, that's ~126 TB/month of egress. At AWS's ~$0.09/GB egress rate, that's roughly $11,340/month just in data transfer. Consider response compression (gzip/brotli), pagination, and field filtering to reduce payload size before scaling infrastructure.

Limitations to Know

• •This calculator models steady-state throughput and does not account for traffic burst patterns, cold starts, cache hit ratios, database query latency, or downstream service bottlenecks — all of which affect real-world API capacity.
• •Burst capacity server defaults are approximations. Actual burst limits depend on your specific configuration (Nginx worker settings, AWS account quotas, Cloudflare plan tier). Always verify against your provider's actual limits.
• •Bandwidth estimates assume uncompressed payloads. Real-world bandwidth with gzip/brotli compression can be 50–80% lower for text-based responses (JSON, HTML, XML), making the calculator conservative for compressible payloads.
• •Per-user RPM assumes uniform load distribution across users, which is rarely true in practice. A small fraction of power users often generates the majority of requests. Use this calculator for aggregate planning, then instrument actual usage to identify your real per-user distribution.

Sources

• Rate Limiting
• Rate Limiting