Emily Chen·
Built sliding-window rate limiting that's actually distributed-safe across our 4 pods
Implements rate limiting middleware with multiple algorithms, tiered limits, and distributed support.
Rate Limiting & Throttling Middleware
You are a backend engineer implementing production rate limiting. Build complete, distributed-safe rate limiting middleware.
## Rate Limiting Spec
- Framework: {{framework}} (Express, Fastify, Django, Spring, etc.)
- Language: {{programming_language}}
- Storage: {{storage_backend}} (Redis, in-memory, PostgreSQL)
- Deployment: {{deployment_mode}} (single-instance, distributed, serverless)
## Requirements
1. **Algorithm Selection** - Implement these strategies:
- Token Bucket (burst-friendly)
- Sliding Window Log (precise)
- Sliding Window Counter (approximate, memory-efficient)
- Fixed Window (simplest)
2. **Tiered Limits** - Different limits per:
- API key tier (free/pro/enterprise)
- Endpoint sensitivity (/auth stricter than /public)
- User vs anonymous
3. **Response Headers** - Return standard headers:
- X-RateLimit-Limit
- X-RateLimit-Remaining
- X-RateLimit-Reset
- Retry-After (on 429)
4. **Middleware Integration** - Drop-in middleware for {{framework}}
5. **Distributed Safety** - Atomic operations, no race conditions
6. **Client Identification** - By API key, IP, user ID, or custom extractor
7. **Whitelist/Blacklist** - Per-client override rules
8. **Event Hooks** - Callbacks on throttle events for monitoring
9. **Graceful Degradation** - Fail-open if storage unavailable
10. **Custom Responses** - Configurable 429 response body
## Output
1. Complete middleware implementation
2. Framework-specific integration (app.use / router / etc.)
3. Configuration examples for each algorithm
4. Rate limit header flow diagram
5. Unit tests for each algorithm
6. Benchmark comparison of algorithms
Ergebnisse
Distributed rate-limit middleware for Express (TypeScript) backed by Redis. Atomic Lua keeps it race-free across instances.
```typescript
// Sliding-window counter via a single atomic Lua script
const SCRIPT = `
local k, now, window, limit = KEYS[1], tonumber(ARGV[1]), tonumber(ARGV[2]), tonumber(ARGV[3])
redis.call('ZREMRANGEBYSCORE', k, 0, now - window)
local count = redis.call('ZCARD', k)
if count >= limit then return {0, count} end
redis.call('ZADD', k, now, now .. ':' .. math.random())
redis.call('PEXPIRE', k, window)
return {1, count + 1}
`;
export function rateLimit(redis: Redis, tier: Tier) {
return async (req, res, next) => {
const id = req.header("x-api-key") ?? req.ip;
const { limit, windowMs } = TIERS[tier]; // free/pro/enterprise
const [ok, count] = (await redis.eval(SCRIPT, 1, `rl:${id}`,
Date.now(), windowMs, limit)) as [number, number];
res.set("X-RateLimit-Limit", String(limit));
res.set("X-RateLimit-Remaining", String(Math.max(0, limit - count)));
if (!ok) {
res.set("Retry-After", String(Math.ceil(windowMs / 1000)));
return res.status(429).json({ error: "rate_limited" });
}
next();
};
}
```
**Tiers:** `free` 60/min, `pro` 600/min, `enterprise` 6000/min; `/auth` routes get a stricter override. **Fail-open:** if `redis.eval` throws, the wrapper calls `next()` so an outage never blocks traffic.
Modell: Claude Sonnet 4
7 Likes3 SavesScore: 3