API Rate Limiting with Redis

What this prompt does

This prompt makes the AI a backend engineer implementing a rate limiting system using Redis for a [framework] API serving [rps] requests per second. It covers the core Redis algorithm, tiered configuration, endpoint-specific overrides, response handling, graceful degradation, and monitoring. Step one writes the atomic Lua script for the [algorithm] algorithm using [key_format] keys, returning the current count, remaining allowance, and reset timestamp.

The structure works because production rate limiting has two non-negotiable parts: atomicity and a fallback. The Lua script runs check-and-increment atomically inside Redis so concurrent requests at [rps] scale can't race past the limit, and it returns the current count, remaining allowance, and reset timestamp in one round-trip. The graceful-degradation step adds an in-memory [fallback_algorithm] limiter with conservative defaults for when Redis is unavailable, and when Redis recovers it reconciles by taking the higher of the two counts so clients aren't handed a fresh allowance mid-outage. Tiered limits separate anonymous, free, and premium clients, with per-endpoint overrides like tighter write and upload caps layered on top through a configuration DSL.

When to use it

• Your API needs rate limiting that holds under real concurrent load
• You want an atomic Redis implementation rather than a race-prone read-then-write
• You need tiered limits across anonymous, free, and premium clients
• You want stricter caps on write and upload endpoints than reads
• You need a sane fallback for when Redis blips
• You want standard rate-limit headers and a monitoring view of allowed-versus-rejected traffic
• You need tier configs in [config_store] cached and refreshed without a lookup per request

Example output

Expect implementation-focused output: the atomic Lua script for [algorithm] with [key_format] keys and correctly set TTLs that auto-expire windows, a tiered configuration loaded from [config_store] and cached in memory with a [config_refresh] interval, an endpoint-override DSL mapping route patterns to specific limits, response handling that sets X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, and Retry-After headers and returns HTTP 429 with a JSON body, the in-memory [fallback_algorithm] degradation path, and a monitoring section exposing allowed-versus-rejected and Redis-latency metrics in [metrics_format]. It's structured as labeled steps for [framework].

Pro tips

• Keep the check-and-increment in a single Lua script; splitting it across round-trips reintroduces the race you're trying to avoid
• Set TTLs correctly so windows auto-expire — a missing TTL silently leaks keys and skews counts
• Use the [key_format] default's client-plus-endpoint shape so limits are scoped where you expect
• On Redis recovery, take the higher of the in-memory and Redis counts so clients don't get a free reset mid-outage
• Cache [config_store] tiers in memory with a [config_refresh] interval to avoid a lookup on every request
• Always return Retry-After on a 429; well-behaved clients use it to back off instead of retry-storming