How do you design rate limiting for an API?

Rate limiting protects availability, enforces fair use and limits abuse. The algorithm determines burst behavior. Fixed windows are simple but allow a burst at the boundary. Token bucket allows controlled bursts up to the bucket size while enforcing an average rate.

function allow(bucket, now) {
  const elapsed = now - bucket.updatedAt;
  bucket.tokens = Math.min(
    bucket.capacity,
    bucket.tokens + elapsed * bucket.refillPerMs,
  );
  bucket.updatedAt = now;

  if (bucket.tokens < 1) return false;
  bucket.tokens -= 1;
  return true;
}

Design decisions

• Key by identity when possible, not only by IP, because NAT shares addresses
• Use different limits for different endpoints and plans
• Store counters in Redis with an atomic script or a single command
• Return 429 with Retry-After and a clear error body
• Consider a local in-process limiter plus a shared limiter to reduce Redis load
• Exclude health checks and protect internal callers deliberately

The distributed version is the hard part. A read, compare and write in application code races across instances. Use a Lua script or a data structure that performs the increment and expiry atomically. Also decide whether limits are per second, per minute or a quota, and how the client discovers them.