What this prompt does
This prompt builds a complete rate limiting system for a Node.js [framework] API. It asks the AI to implement the [algorithm] algorithm backed by [store], apply tiered limits by [tier_basis] (the [tiers] you define), add per-endpoint caps for [sensitive_endpoints], emit standard rate-limit headers, work across [instance_count] instances, provide an internal-service bypass, return clean 429 responses, expose monitoring metrics, and ship with unit and integration tests — including race-condition tests.
The structure works because rate limiting is deceptively easy to get wrong once you scale past one instance. By naming [store] (Redis for shared state) and [instance_count], the output is forced to address distributed counting rather than naive in-memory limits that break behind a load balancer. The explicit request for race-condition tests is the part that matters most: concurrent requests hitting the same counter is exactly where homegrown limiters silently over- or under-count.
When to use it
- When an API you shipped starts taking real traffic and needs protection
- When you sell subscription plans and need tiered limits by
[tier_basis] - When abuse-prone endpoints like login or upload need tighter per-endpoint caps
- When you scale to multiple instances and in-memory limiting no longer works
- When you need to return spec-compliant rate-limit headers to API consumers
- When you want a clean middleware you can drop into an existing
[framework]app - When you need the standard rate-limit headers so well-behaved clients can self-throttle and back off correctly
Example output
You get a TypeScript implementation centered on a clean middleware interface: the limiter logic for [algorithm], the [store] adapter, tier and per-endpoint configuration covering [tiers] and [sensitive_endpoints], header-setting code for the standard rate-limit headers, the 429 response shape with backoff guidance, and a test suite covering the limits and race conditions. The distributed counting logic accounts for [instance_count] instances sharing state, and the internal-service bypass is wired so trusted callers skip the limit. It reads as a drop-in module plus tests rather than a conceptual sketch, with the monitoring metrics (request counts, rejection rate, top limited users) exposed for a dashboard.
Pro tips
- Use Redis for
[store]once[instance_count]is greater than one; in-memory counters diverge across nodes and undercount real usage - Define
[tiers]to match your billing exactly so the limiter and your pricing page never disagree - Set
[sensitive_endpoints]caps tighter than your global limits — login and password reset deserve their own strict windows independent of plan - Keep the sliding-window choice in
[algorithm]; fixed windows allow bursts at the boundary that smooth windows prevent - Insist the race-condition tests actually fire concurrent requests; serial tests pass while the real bug hides under load
- Document the internal-service bypass keys carefully so they cannot leak and become an abuse vector
