Every public-facing API needs a way to say "slow down" before a flood of requests collapses the system. Rate limiting is the first line of defence against denial-of-service attacks, misbehaving clients, runaway retry loops, and simple misconfiguration. Without it, a single bad actor or a bug in a partner integration can saturate your database connection pool, exhaust thread pools, and cascade failures across every microservice downstream.

The token bucket is the most widely deployed rate limiting algorithm in production. It models a bucket that holds up to B tokens (the burst capacity). Tokens are added at a steady rate of R tokens per second. Each request consumes one token. If the bucket is empty, the request is rejected (or queued). This naturally allows short bursts up to B while enforcing an average rate of R.

[Refill: R tokens/sec] --> [Bucket: max B tokens] --> [Request arrives: take 1 token]
                                                          |
                                                   bucket empty? --> 429 Too Many Requests

-- KEYS[1] = rate limit key
-- ARGV[1] = bucket capacity (B)
-- ARGV[2] = refill rate per second (R)
-- ARGV[3] = current timestamp (seconds)
-- ARGV[4] = tokens to consume (usually 1)

local key = KEYS[1]
local capacity = tonumber(ARGV[1])
local refill_rate = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local requested = tonumber(ARGV[4])

local bucket = redis.call("hmget", key, "tokens", "last_refill")
local tokens = tonumber(bucket[1]) or capacity
local last_refill = tonumber(bucket[2]) or now

-- Calculate tokens to add since last refill
local elapsed = math.max(0, now - last_refill)
local new_tokens = math.min(capacity, tokens + elapsed * refill_rate)

if new_tokens >= requested then
  new_tokens = new_tokens - requested
  redis.call("hmset", key, "tokens", new_tokens, "last_refill", now)
  redis.call("expire", key, math.ceil(capacity / refill_rate) * 2)
  return {1, new_tokens}  -- allowed, remaining
else
  redis.call("hmset", key, "tokens", new_tokens, "last_refill", now)
  redis.call("expire", key, math.ceil(capacity / refill_rate) * 2)
  return {0, new_tokens}  -- denied, remaining
end

Stripe uses a token bucket approach for their API rate limiting. Each API key gets a bucket sized to its plan tier. The token bucket is ideal when you want to allow controlled bursts (e.g., a batch import) while maintaining a long-term average rate.

The leaky bucket is the dual of the token bucket. Think of a bucket with a hole in the bottom that leaks at a constant rate. Requests enter the top of the bucket (a FIFO queue). If the bucket (queue) is full, new requests are dropped. The bucket drains at a fixed rate, so outgoing requests are perfectly smoothed — no bursts at all on the output side.

[Incoming requests] --> [Queue (max size Q)] --> drains at rate R --> [Backend service]
                          |                                          
                     queue full? --> 429 Rejected

Shopify historically used a leaky bucket for their REST Admin API. Each app got a bucket of 40 requests that leaked at 2 requests/second, giving a maximum sustained rate of 2/sec with the ability to absorb a short burst of 40.

The simplest algorithm: divide time into fixed windows (e.g., every 60-second block starting at :00) and maintain a counter per window. When a request arrives, increment the counter for the current window. If counter > limit, reject. At the start of a new window, the counter resets to zero.

-- Naive approach: INCR + EXPIRE is NOT atomic
-- Two commands = race condition window
local count = redis.call("INCR", KEYS[1])
if count == 1 then
  redis.call("EXPIRE", KEYS[1], tonumber(ARGV[1]))
end
return count

GitHub uses a fixed window approach for some of their REST API limits (5 000 requests per hour per authenticated user). The simplicity is attractive at scale — just one INCR per request — but the boundary burst issue means actual instantaneous load can be up to 2x the nominal limit.

To fix the boundary burst problem, the sliding window log tracks the exact timestamp of every request in a sorted set. When a new request arrives, remove all entries older than the window size, count remaining entries, and accept or reject. This gives a perfect per-user rate limit with no boundary issues.

-- KEYS[1] = rate limit key
-- ARGV[1] = window size in seconds
-- ARGV[2] = max requests per window
-- ARGV[3] = current timestamp (microseconds for precision)

local key = KEYS[1]
local window = tonumber(ARGV[1])
local limit = tonumber(ARGV[2])
local now = tonumber(ARGV[3])

-- Remove entries outside the window
redis.call("ZREMRANGEBYSCORE", key, 0, now - window * 1000000)

-- Count remaining entries
local count = redis.call("ZCARD", key)

if count < limit then
  -- Add current request timestamp as both score and member
  redis.call("ZADD", key, now, now .. ":" .. math.random(1000000))
  redis.call("EXPIRE", key, window + 1)
  return {1, limit - count - 1}  -- allowed, remaining
else
  redis.call("EXPIRE", key, window + 1)
  return {0, 0}  -- denied, 0 remaining
end

The sliding window log is the gold standard for accuracy. It is commonly used for authentication-related limits (login attempts, password resets) where the limit is low and precision matters more than memory efficiency.

The sliding window counter is the practical sweet spot — it combines the low memory of fixed windows with an approximation of sliding window accuracy. It keeps counters for the current and previous fixed windows, then uses a weighted formula to estimate the count in the sliding window.

Timeline:  |----prev window (count=80)----|----current window (count=20)----|
                                          ^-- 70% overlap --^-- 30% elapsed
           Estimated sliding count = 80 * 0.70 + 20 = 76

-- KEYS[1] = current window key, KEYS[2] = previous window key
-- ARGV[1] = limit, ARGV[2] = window size (sec)
-- ARGV[3] = current timestamp

local curr_key = KEYS[1]
local prev_key = KEYS[2]
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local now = tonumber(ARGV[3])

local curr_start = math.floor(now / window) * window
local elapsed = now - curr_start
local weight = 1 - (elapsed / window)

local prev_count = tonumber(redis.call("GET", prev_key) or "0")
local curr_count = tonumber(redis.call("GET", curr_key) or "0")

local estimated = prev_count * weight + curr_count

if estimated < limit then
  redis.call("INCR", curr_key)
  redis.call("EXPIRE", curr_key, window * 2)
  return {1, math.floor(limit - estimated - 1)}
else
  return {0, 0}
end

In a single-node system, an in-memory counter with a mutex works fine. But production systems run behind load balancers with dozens of application servers. If each node keeps its own counter, a user with a limit of 100/min could send 100 requests to each of N nodes, achieving N * 100 total requests. You need a shared, centralized counter — and that introduces distributed systems challenges.

A well-designed rate limiter communicates its state to clients through standard HTTP headers so that well-behaved clients can self-throttle and avoid hitting limits in the first place.

Stripe returns X-RateLimit-Limit and X-RateLimit-Remaining on every response, not just 429s. This lets clients monitor their consumption proactively. GitHub includes X-RateLimit-Reset as a Unix timestamp and offers a /rate_limit endpoint to check status without consuming a request.

Where you place the rate limiter has major implications for latency, accuracy, and operational complexity.

For most applications, per-region independent limits with a known multiplier (total effective limit = per-region limit * active regions) is the simplest approach. Reserve global centralized counting for scenarios where over-limit has real cost — billing, compliance, or security-critical endpoints.