API Rate Limiting Strategies: A 2026 Engineering Guide

Rate limiting sits at the intersection of reliability, cost control, and security. OWASP calls the failure mode API4: Unrestricted Resource Consumption — without limits, one client can exhaust capacity, run up your bill, or brute-force credentials. We build APIs that take real traffic, and our custom software practice treats limiting as a day-one control. For the full API hardening picture, pair this with our API security best practices guide.

Four algorithms cover almost every real need. The right choice is a tradeoff between burst tolerance, accuracy, and memory.

• Fixed window. Count requests per calendar window (e.g. per minute). Simple, but a client can send a full window's worth right before the reset and again right after — double the intended rate across the boundary.
• Sliding window log. Store a timestamp per request and count those inside the trailing window. Perfectly accurate, but memory grows with traffic.
• Sliding window counter. Approximate the sliding window by weighting the current and previous fixed windows. Near-accurate with constant memory — a great default for high throughput.
• Token bucket. Refill tokens at a steady rate up to a cap; each request spends one. Permits bursts up to the bucket size, then throttles to the refill rate. The best fit for user-facing APIs.

A token bucket needs only two stored values per key — the current token count and the timestamp of the last refill. On each request you compute how many tokens have accrued since then, cap at the bucket size, and spend one if available.

// Token bucket: refill lazily on each request
function allow(state, now, ratePerSec, capacity) {
  const elapsed = (now - state.lastRefill) / 1000;
  const tokens = Math.min(capacity, state.tokens + elapsed * ratePerSec);
  if (tokens < 1) {
    return { ok: false, retryAfter: (1 - tokens) / ratePerSec };
  }
  return {
    ok: true,
    next: { tokens: tokens - 1, lastRefill: now },
  };
}

The key design decision is scope: rate-limit per authenticated identity for fairness, and per IP as a backstop against unauthenticated abuse. Use distinct, stricter buckets for expensive or sensitive endpoints — login, password reset, search, export, and anything that triggers downstream cost.

In-memory counters break the moment you run more than one instance — each server enforces its own limit, so a client's real allowance is multiplied by your fleet size. The fix is shared, atomic state.

-- Atomic fixed-window counter in Redis (Lua, runs server-side)
local current = redis.call("INCR", KEYS[1])
if current == 1 then
  redis.call("PEXPIRE", KEYS[1], ARGV[1])  -- window in ms
end
if current > tonumber(ARGV[2]) then        -- limit
  return 0                                  -- reject
end
return 1                                     -- allow

• Use a Lua script or a pipelined transaction so the read-modify-write is atomic — otherwise concurrent requests race past the limit.
• For extreme throughput, keep a node-local token bucket and reconcile with Redis periodically; you trade a little precision for far fewer round trips.
• Push coarse limiting to the edge — a CDN, API gateway, or WAF — and reserve application-level limiting for per-tenant fairness and business logic.

A rate limiter is only as good as the signal it sends back. Return 429 Too Many Requests with a Retry-After header, and emit the standardized RateLimit-* headers so disciplined clients throttle themselves before hitting the wall.

• RateLimit-Limit — the ceiling for the window.
• RateLimit-Remaining — requests left in the current window.
• RateLimit-Reset — seconds until the window refreshes.
• Never return 200 with an error body — HTTP clients and proxies rely on the 429 status to trigger automatic backoff.

Document your limits publicly. A client that knows the rules can design polite retry-with-jitter behavior; a client guessing in the dark will hammer you.

Limits drift out of step with reality unless you watch them:

• Instrument every rejection. A spike in 429s is either an attack or a limit set too low for a legitimate workload — you cannot tell them apart without metrics. See our observability for startups guide.
• Decide fail-open vs fail-closed per endpoint. Sensitive endpoints reject when the limiter is down; low-risk reads stay available. Make it explicit and alert on degradation.
• Offload heavy work to a queue. When a tenant hits their limit on an expensive operation, enqueue it rather than rejecting outright — see background jobs and queues in production.