@nestjs/throttler

@nestjs/throttler is NestJS’s official rate-limiting module, providing a ThrottlerGuard and @Throttle() decorator that apply request-rate limits consistently across every transport NestJS supports — HTTP (Express or Fastify), GraphQL resolvers, WebSocket gateways, and microservice RPC handlers — through one shared API rather than a separate rate-limiting library per transport.

It’s built as a standard NestJS dynamic module (ThrottlerModule.forRoot()/forRootAsync()) with a pluggable storage interface, so the default in-memory limiter can be swapped for Redis or another distributed store when running multiple application instances behind a load balancer.

What You Get

• ThrottlerModule.forRoot()/forRootAsync() for global rate-limit configuration, following standard NestJS dynamic-module conventions
• A ThrottlerGuard that can be applied globally, per-controller, or per-route via NestJS’s guard system
• @Throttle() and @SkipThrottle() decorators for overriding or exempting specific routes from the global limit
• Multiple named throttler configurations (e.g. short/medium/long windows) applied simultaneously to the same route
• Uniform behavior across HTTP (Express/Fastify), GraphQL resolvers, WebSocket gateways, and RPC/microservice handlers
• A pluggable ThrottlerStorage interface so the default in-memory store can be replaced with Redis or another distributed backend

Common Use Cases

• Protecting public API endpoints (login, signup, password reset) from brute-force and credential-stuffing attempts
• Applying different rate-limit tiers to different routes (e.g. stricter limits on auth routes, looser on general API routes)
• Rate-limiting GraphQL resolvers or WebSocket gateway events, not just REST endpoints
• Enforcing consistent request quotas across a horizontally-scaled NestJS deployment via a shared Redis-backed throttler storage
• Exempting internal health-check or webhook routes from a global rate limit via @SkipThrottle()

Under The Hood

Architecture — The module follows the standard NestJS dynamic-module pattern: throttler.module.ts wires up forRoot/forRootAsync and registers providers, throttler.guard.ts implements the ThrottlerGuard (a NestJS CanActivate guard) that inspects the current execution context — HTTP request, GraphQL context, WS client, or RPC context — to extract a tracking key and check it against configured limits, and throttler.service.ts holds the core rate-tracking logic against the pluggable ThrottlerStorage interface (throttler-storage.interface.ts), with hash.ts generating storage keys. throttler.decorator.ts implements @Throttle()/@SkipThrottle() using NestJS’s metadata/reflection system to let the guard read per-route overrides.

Tech Stack — TypeScript, built directly against @nestjs/core/@nestjs/common as peer dependencies, with no rate-limiting algorithm dependency of its own — the storage abstraction means Redis-backed limiting is added via a separate community storage adapter rather than a bundled client. Managed under the official nestjs GitHub organization with renovate.json for automated dependency updates.

Code Quality — Core logic has colocated spec files (throttler.guard.spec.ts, throttler.service.spec.ts) alongside a broader test/ suite exercising each supported transport (HTTP, GraphQL, WS, RPC) to confirm the guard behaves consistently across all of them — the main risk area for a cross-transport library. As an official @nestjs/* package it follows the framework’s own release cadence and conventions (CHANGELOG, semantic versioning, CODE_OF_CONDUCT/CONTRIBUTING docs) and has sustained active, well-maintained development.

API Design — Adoption is typically two lines: register ThrottlerModule.forRoot([{ ttl, limit }]) at the module level and apply ThrottlerGuard globally via APP_GUARD, after which every route is protected without per-route code. Overrides stay declarative via @Throttle({ default: { limit, ttl } })/@SkipThrottle() decorators rather than imperative guard logic, keeping rate-limit policy visible directly on the controller/route it applies to.