Most rate limiters are slow and inaccurate. I built one that’s 50% faster and 99% precise.
Standard NestJS throttlers make 3 separate Redis calls per request. That’s 3 network round-trips, ~2-3ms latency, and potential race conditions.
Worse? Fixed window algorithms allow 2x burst at boundaries. Your “100 requests/minute” limit becomes 200 requests in 1 second.
So I built nestjs-sliding-window-throttler.
One atomic Redis operation. True sliding window with timestamp tracking. Zero race conditions.
The results:
⚡ 50% lower latency (~1ms vs ~2-3ms)
🎯 99% accuracy vs 70% for fixed window
🚀 2-3x higher throughput
✨ Single network round-trip instead of three
Uses Redis 7.0+ Functions with automatic Lua fallback for older versions. Drop-in replacement for @nestjs/throttler with full TypeScript support.
Perfect for security-critical endpoints where precision matters — login attempts, password resets, expensive API calls.
The video shows how different algorithms handle the same request pattern. Links here 👇
📦 npm: <a href="http://npmjs.com/package/nestjs-sliding-window-throttler" target="_blank" rel="noopener nofollow">npmjs.com/package/nestjs-sliding-window-throttler</a>
🔗 GitHub: <a href="http://github.com/orknist/nestjs-sliding-window-throttler" target="_blank" rel="noopener nofollow">github.com/orknist/nestjs-sliding-window-throttler</a>
📖 Algorithm explained: <a href="http://github.com/orknist/nestjs-sliding-window-throttler/blob/main/docs/algorithm.md" target="_blank" rel="noopener nofollow">github.com/orknist/nestjs-sliding-window-throttler/blob/main/docs/algorithm.md</a>
<a href="https://www.linkedin.com/search/results/all/?keywords=%23nestjs&amp;origin=HASH_TAG_FROM_FEED" target="_blank" rel="noopener nofollow">#NestJS</a> <a href="https://www.linkedin.com/search/results/all/?keywords=%23typescript&amp;origin=HASH_TAG_FROM_FEED" target="_blank" rel="noopener nofollow">#TypeScript</a> <a href="https://www.linkedin.com/search/results/all/?keywords=%23redis&amp;origin=HASH_TAG_FROM_FEED" target="_blank" rel="noopener nofollow">#Redis</a> <a href="https://www.linkedin.com/search/results/all/?keywords=%23ratelimiting&amp;origin=HASH_TAG_FROM_FEED" target="_blank" rel="noopener nofollow">#RateLimiting</a> <a href="https://www.linkedin.com/search/results/all/?keywords=%23backendengineering&amp;origin=HASH_TAG_FROM_FEED" target="_blank" rel="noopener nofollow">#BackendEngineering</a> <a href="https://www.linkedin.com/search/results/all/?keywords=%23opensource&amp;origin=HASH_TAG_FROM_FEED" target="_blank" rel="noopener nofollow">#OpenSource</a> <a href="https://www.linkedin.com/search/results/all/?keywords=%23performance&amp;origin=HASH_TAG_FROM_FEED" target="_blank" rel="noopener nofollow">#Performance</a>

Welcome to the NestJS Developers Hub, a collaborative community for developers passionate about NestJS! Whether you're a seasoned expert or just getting started, this group is dedicated to sharing knowledge, solving problems, and advancing our skills

Nestjs Developers

A new NestJS library called nestjs-sliding-window-throttler addresses performance and accuracy issues with the standard @nestjs/throttler. The standard throttler makes 3 separate Redis calls per request, causing ~2-3ms latency and potential race conditions, while fixed-window algorithms allow up to 2x burst traffic at window boundaries. This drop-in replacement uses a single atomic Redis operation with true sliding window timestamp tracking, achieving ~1ms latency, 99% accuracy, and 2-3x higher throughput. It leverages Redis 7.0+ Functions with automatic Lua fallback for older versions, making it suitable for security-critical endpoints like login attempts and password resets.

nestjs-sliding-window-throttler

Isn’t it the purpose for a rate limiter to be … “slow” ?