Rate Limit Calculator

Rate Limiting: Protecting APIs from Themselves

Every API needs rate limiting. Without it, a single misbehaving client can degrade service for everyone, drive infrastructure costs through the roof, or crash your downstream systems. With it, you set clear expectations, protect resources, and enable predictable scaling. The challenge is picking the right algorithm, the right limits, and the right enforcement layer.

The Algorithms

Four common rate-limiting algorithms, each with different tradeoffs:

Token Bucket

A bucket holds up to B tokens. Each request removes one token. Tokens refill at rate R tokens/second up to capacity B. If the bucket is empty, requests are rejected (or queued).

Behavior: bursty. A client can spend the full bucket all at once (a burst of B requests), then is throttled to the refill rate R.

Parameters:

• B = burst capacity (how many requests in quick succession)
• R = sustained rate (long-term average)

Math: max sustained QPS = R. Max burst = B. Time to refill from empty = B/R seconds.

Example: B=100, R=10/s → 100 requests in 1 second OK, then 10/s after. Refill takes 10 seconds.

Leaky Bucket

A queue holds up to Q requests. Requests enter the queue; the queue drains at fixed rate L/second. If the queue overflows, new requests are rejected.

Behavior: smooth. Output rate is constant at L/second regardless of input pattern.

Use case: protecting downstream systems that prefer steady load over bursts (databases, third-party APIs with their own limits).

Math: max output QPS = L. Max queue depth = Q (also: max added latency = Q/L seconds).

Example: Q=100, L=10/s → queue smooths bursts; if 100 arrive at once, last one waits ~10s for drain.

Fixed Window Counter

Count requests per window (e.g., per minute). Reset counter at window boundaries. Reject if counter exceeds limit.

Behavior: simple but flawed at boundaries.

Pitfall: a client can send N requests at the end of one window and N at the start of the next, total 2N in a 2-second span when the limit is N per minute.

Math: max requests = N per fixed window of W seconds. Worst case burst = 2N over W seconds.

Use case: low-stakes APIs where the 2× boundary effect is acceptable (most public APIs).

Sliding Window Log

Store timestamps of all requests in the past window. Count requests within the window at request time. Drop old timestamps.

Behavior: accurate. No boundary effect.

Cost: memory per user (one timestamp per request in window).

Math: at most N requests in any W-second sliding window.

Use case: precise rate limiting; expensive at high QPS.

Sliding Window Counter (Approximation)

A hybrid: weighted average of two adjacent fixed windows. If 75% through the current window, count = (0.25 × previous window) + (current window).

Behavior: close to true sliding window with constant memory (just two counters).

Use case: production-grade rate limiting at scale (e.g., Cloudflare's edge limiter uses this).

Which Algorithm to Use?

Sizing the Limits

A common mistake: setting limits without measuring. The process:

1. Measure baseline. What's the legitimate use pattern? P50 and P99 requests per minute per user.
2. Identify the bottleneck. Database connections, CPU, downstream API quota?
3. Calculate headroom. Set limit so bottleneck stays at 60-70% utilization at full capacity.
4. Choose burst tolerance. How spiky is normal usage? Token Bucket with burst = 5-10× sustained handles most interactive workloads.
5. Differentiate by tier. Free vs paid users; per-endpoint (cheap vs expensive operations).

Example math:

• Database can handle 1000 QPS.
• Average user makes 10 requests in a session, in 5 seconds.
• 100 concurrent users → ~200 QPS baseline.
• Headroom for 5× growth → cap at 500 QPS shared.
• Per-user: 100 req/min sustained, burst 30 in 5 seconds.

Token Bucket: B=30, R=100/60=1.67/s per user.

Where to Enforce

Multi-layer defense:

Edge (CDN/gateway): per-IP limits to drop obvious abuse (DDoS, scrapers). Stateless, cheap, fast. Doesn't know about your business logic.

API gateway: per-API-key / per-user limits based on plan. Stateful (counter store: Redis is standard). Knows about authenticated users.

Application: per-feature / per-endpoint limits within authenticated context. E.g., "any user can call /search 60/min, but only Pro users can call /export 10/hour."

Downstream: connection pool limits, retry budgets, circuit breakers. Protects DB / third-party APIs even if upper layers fail.

Storing Counters

For accurate rate limiting at scale, you need shared state across servers. Common choices:

Redis with INCR + EXPIRE: atomic, fast. Standard for production. ~1ms latency added per request.

Local in-memory (per-server): fast but inaccurate if traffic isn't sticky-routed. Limits are effectively per-server, not per-user.

Database table: too slow for the request path. Useful for daily/monthly quotas (eventual consistency OK).

API gateway built-in (AWS API Gateway, Kong, Cloudflare): handles storage for you; reasonable defaults.

For Token Bucket / Leaky Bucket, you also need to track refill timestamps. A standard Redis-Lua script handles this atomically.

Responding to Rate-Limited Clients

When a request exceeds the limit:

Status code: 429 Too Many Requests (RFC 6585).

Headers:

• Retry-After: <seconds>, when the client can try again
• X-RateLimit-Limit: <max>, the limit
• X-RateLimit-Remaining: <n>, requests left in current window
• X-RateLimit-Reset: <epoch>, when the window resets (some APIs use seconds-until-reset instead)

(There's no fully standardized header set; GitHub, Twitter, Stripe all do it slightly differently. Document yours.)

Response body: clear message: "Rate limit exceeded. Retry in 30 seconds." Avoid generic 500-style errors.

Client Behavior

Well-behaved clients respect rate limits:

1. Read Retry-After. Don't immediately retry; wait the suggested time.
2. Exponential backoff with jitter. If no Retry-After, wait min(60, 2^attempt + random(0, 1)) seconds. Jitter prevents thundering-herd retries.
3. Circuit break. After repeated 429s, stop trying for a while; signal "service degraded" upstream.
4. Distribute load. If you have a rate limit of 10/s and 100 jobs, schedule them over 10 seconds, not all at once.

Server-side rate limiting protects you against bad clients; good clients also protect themselves with these patterns.

Cost vs Free Tiers

Rate limits are a business tool:

• Free tier: low enough that the cost of serving free users is small, high enough that the API is useful.
• Paid tiers: scale with willingness to pay. Stripe-like APIs scale by request volume; others by feature access.
• Overages: charge per request beyond the limit, or hard-block. Hard-blocking is operationally simpler; metered overages capture more revenue from heavy users.

Models to compare:

1. Hard limit: free tier capped, must upgrade. Predictable cost, friction at limit.
2. Soft limit + overage: charge per request over the limit. Frictionless, less predictable for users.
3. Burstable: small sustained limit but large burst capacity. Friendly to ad-hoc use.

Common Pitfalls

No rate limiting on auth endpoints. Credential-stuffing attacks hit login endpoints at high QPS. Strict rate limits on /login, /reset-password are critical, much lower than other endpoints.

Same limit for all endpoints. A cheap endpoint (/health) and an expensive one (/export) shouldn't share quota. Per-endpoint limits or weighted limits (where each endpoint consumes N "tokens" based on cost) are better.

Per-IP only, no per-user. NAT'd users (mobile networks, corporate networks) share IPs; one bad user gets everyone limited. Authenticated users should have per-account limits.

Limits too low at start. Friction during launch when limits trigger on legitimate users. Start higher than you think; tighten as you observe patterns.

No monitoring of rate-limit hits. You should know when users are hitting limits, it's a signal of legitimate growth or attack. Dashboard the 429 rate.

Privacy

This calculator is browser-side arithmetic on parameters you input. Bucket sizes, refill rates, target QPS, none of it leaves the page. Open DevTools Network during use: zero outbound requests. Useful because rate-limit parameters can reveal infrastructure capacity and business projections (e.g., "free tier = 100 req/min × 50K users = ..."), which aren't things to feed to a third-party calculator.