Knowledge · APIs

Rate limiting with Unix timestamps

Fixed window algorithm

Increment a counter for identity:epochBucket. Expire keys automatically with Redis TTL = window length + small slack. Simplicity comes at a cost: a burst of traffic at the boundary can consume twice the nominal allowance. Document that behavior in developer portals so mobile teams do not assume strict fluid limits.

const window = 60;
const bucket = Math.floor(Date.now() / 1000 / window);
const key = `rl:${userId}:${bucket}`;
// INCR + EXPIRE at window boundary (pseudocode)

Sliding window in Redis

Maintain a sorted set where scores are Unix seconds (or ms) of each accepted request. Before accepting a new request, delete members older than now - width. Cardinality approximates recent volume; for exact counts you pay memory proportional to allowed RPS × window.

async function slidingAllow(redis, id, limit, widthSec) {
  const key = `sw:${id}`;
  const now = Math.floor(Date.now() / 1000);
  await redis.zRemRangeByScore(key, 0, now - widthSec);
  const count = await redis.zCard(key);
  if (count >= limit) return false;
  await redis.zAdd(key, { score: now, value: crypto.randomUUID() });
  await redis.expire(key, widthSec * 2);
  return true;
}

Token bucket refill

Store tokens and last_refill_epoch. On each check, compute delta = now - last, add delta * refill_per_sec capped by capacity, then consume one token if available. Floating math in Lua scripts inside Redis avoids race conditions between read and write.

Algorithm comparison

Key takeaways

• Never derive limiter time solely from client devices.
• Publish reset headers as integer epochs, not human strings.
• Use atomic Redis primitives under concurrency — no read-modify-write in app code alone.
• Load test boundary seconds; off-by-one in floor division causes duplicate keys.
• Pair limiters with backoff hints (Retry-After) derived from same clock.

Tutorial: Rate limiting algorithms