What this prompt does
This prompt asks the AI to design a distributed rate limiter for [api_scale] requests per second across [region_count] regions. It compares the four classic algorithms (token bucket, sliding window log, sliding window counter, fixed window), recommends [algorithm] for your case and explains why, then covers a Redis-based atomic implementation, multi-region sync, X-RateLimit-* headers, per-user/IP/key limits, graceful degradation, hot-reloading config, monitoring, and a client SDK.
The structure works because rate limiting has well-known algorithms with sharp tradeoffs, and the right pick depends on your traffic shape. Passing [api_scale] and [region_count] forces the model to confront the hard parts — atomic counter updates under high QPS and keeping limits consistent across regions. Pinning [algorithm] (or asking it to recommend one) anchors the implementation, and the prompt's insistence on atomic Redis operations and a fallback when Redis is unavailable keeps it production-minded rather than a textbook summary.
When to use it
- You're adding rate limiting to a public API and want the algorithm choice justified
- You need atomic Redis logic that's correct under high concurrency
- You operate across
[region_count]regions and need a synchronization strategy - You want correct
X-RateLimit-*headers and per-user, per-IP, and per-key limits - You need a graceful-degradation plan for when Redis is down
- You're comparing token bucket versus sliding window for your traffic pattern
Example output
Expect an algorithm comparison table, a recommendation for [algorithm] with reasoning, pseudocode for the core counter logic using atomic Redis operations (often a Lua script or INCR-with-expiry), a multi-region sync approach, a header spec, and a section on what happens when Redis is unreachable. It also typically includes capacity planning sized to [api_scale].
Pro tips
- Let the model recommend
[algorithm]first, then challenge it; sliding window counter is a common balance of accuracy and cost - Insist on atomic operations in the Redis pseudocode — non-atomic check-then-set is the classic rate-limiter race condition
- Set
[region_count]accurately; one region is simple, but multiple regions force a real consistency decision - Ask explicitly about graceful degradation: fail-open keeps traffic flowing, fail-closed protects the origin — pick deliberately
- Have it produce the
X-RateLimit-*header logic so clients can back off correctly - For
[api_scale], give a real peak QPS so the capacity planning reflects your actual Redis sizing
