DEV Community: Suren Krmoian

Mastering Rate Limiting in NestJS with RedisX

Suren Krmoian — Sun, 15 Mar 2026 10:00:17 +0000

Let's talk about something every API developer faces sooner or later: securing your endpoints without sacrificing performance. Rate limiting is a go-to strategy here. It's all about controlling the traffic load by limiting the number of requests a user can make in a set timeframe. If you're using NestJS, RedisX offers a nifty plugin to handle this with several strategies.

Rate Limiting Strategies Explained

Why so many strategies? Well, different scenarios call for different approaches.

Fixed Window: Think of it as the simplest approach. You reset the request count every fixed period, say a minute. Every new minute, users get a fresh quota. It's simple but not great with bursts of traffic.
Sliding Window: A bit more sophisticated. It considers requests over the last window duration, giving a smoother experience. This one's solid for most cases.
Token Bucket: If you're okay with some bursts, go for this. It lets tokens accumulate, and a request consumes a token. No tokens? No request. Simple.

Getting Started with NestJS RedisX

Alright, let's get this into your NestJS app. First things first, install the packages:

npm install @nestjs-redisx/core @nestjs-redisx/rate-limit

Then, configure your module. Use RateLimitPlugin.registerAsync for flexibility, especially if you're into dynamic configs:

import { Module } from '@nestjs/common';
import { ConfigModule, ConfigService } from '@nestjs/config';
import { RedisModule } from '@nestjs-redisx/core';
import { RateLimitPlugin, RateLimitGuard } from '@nestjs-redisx/rate-limit';
import { APP_GUARD } from '@nestjs/core';

@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),
    RedisModule.forRootAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      plugins: [
        RateLimitPlugin.registerAsync({
          imports: [ConfigModule],
          inject: [ConfigService],
          useFactory: (config: ConfigService) => ({
            defaultAlgorithm: config.get('RATE_LIMIT_ALGORITHM', 'sliding-window'),
            defaultPoints: config.get('RATE_LIMIT_POINTS', 100),
            defaultDuration: config.get('RATE_LIMIT_DURATION', 60),
          }),
        }),
      ],
      useFactory: (config: ConfigService) => ({
        clients: {
          type: 'single',
          host: config.get('REDIS_HOST', 'localhost'),
          port: config.get('REDIS_PORT', 6379),
        },
      }),
    }),
  ],
  providers: [
    { provide: APP_GUARD, useClass: RateLimitGuard },
  ],
})
export class AppModule {}

Limiting Specific Endpoints

Once set up, you can apply rate limits to your routes using the @RateLimit decorator. Great for public APIs:

import { Controller, Get } from '@nestjs/common';
import { RateLimit } from '@nestjs-redisx/rate-limit';

@Controller('api')
export class ApiController {
  @Get('data')
  @RateLimit({ points: 10, duration: 60 })
  getData() {
    return { data: 'rate limited endpoint' };
  }

  @Get('search')
  @RateLimit({ points: 5, duration: 60, key: 'ip' })
  search() {
    return { results: [] };
  }
}

Wrapping Up

Incorporating rate limiting can be a game-changer for your API's security and performance. With NestJS RedisX, you've got a powerful toolkit to do just that. Whether you're managing a bustling app or just want to keep things fair, RedisX has got your back. Dive deeper into the docs at nestjs-redisx.dev for more insights.

Keep It Synchronized: Distributed Locks in NestJS with RedisX

Suren Krmoian — Wed, 11 Mar 2026 10:00:24 +0000

Distributed locking can be a lifesaver when you're juggling multiple instances of an application. You know how it goes—everyone wants a piece of the pie, and without some rules, things get messy. Let’s talk about how to keep the peace with distributed locks in NestJS using RedisX. We'll focus on making sure those locks don't run out of steam and how to prevent deadlocks.

The Need for Distributed Locks

Imagine this: multiple instances of your app trying to update the same data at the same time. Chaos, right? Race conditions, data getting all tangled up, maybe even your system throwing a fit. Distributed locks are like the bouncers of your code, making sure only one instance gets through the door to that critical section at a time.

RedisX to the Rescue

NestJS RedisX is the toolkit you didn't know you needed for handling Redis in your app. It’s got this great @nestjs-redisx/locks package that makes setting up Redis-backed locks a breeze. Auto-renewal? Check. Deadlock prevention? Double check. These features are your safety net in a production environment.

Getting Started with RedisX Locks

First things first, you gotta install some packages:

npm install @nestjs-redisx/core @nestjs-redisx/locks

Next up, configure your Redis module in AppModule like so:

import { Module } from '@nestjs/common';
import { ConfigModule, ConfigService } from '@nestjs/config';
import { RedisModule } from '@nestjs-redisx/core';
import { LocksPlugin } from '@nestjs-redisx/locks';

@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),
    RedisModule.forRootAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      plugins: [
        LocksPlugin.registerAsync({
          imports: [ConfigModule],
          inject: [ConfigService],
          useFactory: (config: ConfigService) => ({
            defaultTtl: config.get('LOCK_DEFAULT_TTL', 30000),
            retry: {
              maxRetries: config.get('LOCK_MAX_RETRIES', 3),
              initialDelay: config.get('LOCK_RETRY_DELAY', 100),
            },
            autoRenew: { enabled: config.get('LOCK_AUTO_RENEW', true) },
          }),
        }),
      ],
      useFactory: (config: ConfigService) => ({
        clients: {
          type: 'single',
          host: config.get('REDIS_HOST', 'localhost'),
          port: config.get('REDIS_PORT', 6379),
        },
      }),
    }),
  ],
})
export class AppModule {}

Using Locks in Your Services

Now, let's put those locks to work. With RedisX set up, you can use the @WithLock decorator to handle locks around your service methods. It does the heavy lifting of acquiring and releasing locks for you.

import { Injectable } from '@nestjs/common';
import { WithLock } from '@nestjs-redisx/locks';

@Injectable()
export class PaymentService {
  @WithLock({ key: 'payment:{0}', ttl: 10000 })
  async processPayment(orderId: string): Promise<Payment> {
    const order = await this.orderRepository.findById(orderId);
    if (order.status === 'paid') {
      throw new PaymentAlreadyProcessedError(orderId);
    }
    const result = await this.paymentGateway.charge(order);
    await this.orderRepository.update(orderId, { status: 'paid' });
    return result;
  }
}

Keeping It Smooth with Auto-Renewal and Deadlocks

RedisX’s lock plugin is smart about keeping locks alive during long operations. Auto-renewal extends the lock's TTL as needed. Plus, if something goes wrong and the lock-holder crashes, deadlock prevention ensures the lock will eventually expire, letting others have a go.

Wrapping It Up

Using RedisX for distributed locking in NestJS not only makes life easier but also boosts your system's reliability. You get to focus on the fun parts of building, while RedisX takes care of the nitty-gritty of keeping things in order. Happy coding!

NestJS RedisX Joins the Awesome NestJS List!

Suren Krmoian — Wed, 11 Mar 2026 01:26:33 +0000

Boom! Big news in the NestJS world. NestJS RedisX just snagged a spot on the Awesome NestJS list. Yep, it's that cool.

So, What’s Awesome NestJS Anyway?

Think of Awesome NestJS as the ultimate toolkit. It's a handpicked collection of resources, libraries, and tools that make building apps with NestJS a breeze. Getting on this list? It’s a nod to our project’s quality and value to devs everywhere.

Why All the Buzz About NestJS RedisX?

NestJS RedisX isn’t just another tool. It’s a powerhouse for Redis in the NestJS ecosystem. Imagine handling caching, distributed locks, rate limiting, streams, and more—all with one Redis connection. That’s what our modular plugin architecture does. Perfect for when you’re building something that needs to work, and work well.

Go See For Yourself

Curious about what makes us tick? We’re on the Awesome NestJS list right here. This recognition fuels our drive to keep delivering solid stuff for the NestJS crowd.

A massive thank you to everyone who’s backed us. Your feedback? It’s gold. Seriously.

Keep in Touch

Want the full scoop? Dive into our documentation or check out our GitHub repo. We’re all about hearing from you, so bring on the thoughts and ideas.

Thanks for being part of our adventure!

Boosting Performance with Two-Tier Caching in NestJS

Suren Krmoian — Tue, 03 Mar 2026 10:00:38 +0000

Boosting Performance with Two-Tier Caching in NestJS

Let's cut right to the chase. If you're building web applications with NestJS, you know performance and scalability are non-negotiable. One way to keep things zippy is by using a two-tier caching strategy. That's where NestJS RedisX comes into play. It's an open-source toolkit that simplifies Redis integration in NestJS apps, making it ridiculously easy to set up a two-layer cache. Let's get our hands dirty with some code and see how you can implement this.

What's Two-Tier Caching Anyway?

Alright, so you've got two levels of caching here. The first level (L1) is your in-memory cache. It's right there on the server with your application, super fast, low latency. But, of course, it's limited by your server's memory.

Then there's the second level (L2), which is a Redis-based cache. This one lives across the network, can store a ton more data, and is shared across multiple instances. So, if L1 doesn't have what you're looking for, L2 steps in before you have to hit the database. Pretty neat, right?

Setting It Up with NestJS RedisX

Now, let's dive into the implementation. With RedisX, setting up this cache is a breeze. Follow these steps to get it rolling.

Step 1: Get the Packages

First things first, you need to install the necessary RedisX packages. Pop open your terminal and run:

npm install @nestjs-redisx/core @nestjs-redisx/cache

Step 2: Configure the Redis Module

Next, you'll want to configure the RedisModule in your AppModule. This is where the magic starts:

import { Module } from '@nestjs/common';
import { ConfigModule, ConfigService } from '@nestjs/config';
import { RedisModule } from '@nestjs-redisx/core';
import { CachePlugin } from '@nestjs-redisx/cache';

@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),
    RedisModule.forRootAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      plugins: [
        CachePlugin.registerAsync({
          imports: [ConfigModule],
          inject: [ConfigService],
          useFactory: (config: ConfigService) => ({
            l1: { enabled: true, maxSize: 1000, ttl: 60 },
            defaultTtl: config.get('CACHE_TTL', 300),
          }),
        }),
      ],
      useFactory: (config: ConfigService) => ({
        clients: {
          type: 'single',
          host: config.get('REDIS_HOST', 'localhost'),
          port: config.get('REDIS_PORT', 6379),
        },
      }),
    }),
  ],
})
export class AppModule {}

Step 3: Use Caching in Your Services

Now, let's put that cache to work. Use the @Cached decorator in your services. It'll check the L1 cache first, then L2, and update both as needed:

import { Injectable } from '@nestjs/common';
import { Cached } from '@nestjs-redisx/cache';

@Injectable()
export class ProductService {
  @Cached({ key: 'product:{0}', ttl: 3600 })
  async getProduct(id: string) {
    return this.db.findProduct(id);
  }
}

Why Bother with Two-Tier Caching?

Speed: L1 cache is lightning fast, reducing latency to virtually nothing.
Scalability: L2 lets you handle big datasets and share that cached goodness across instances.
Efficiency: RedisX’s plugin-based setup is smooth and reduces the load on your database, keeping your app peppy.

Wrapping It Up

There you have it. A two-tier caching system using NestJS RedisX. It's a solid strategy to keep your app running smoothly even under heavy loads. For a deeper dive and more configuration options, check out the NestJS RedisX documentation.

Level Up Your NestJS App with RedisX

Suren Krmoian — Sun, 01 Mar 2026 10:00:28 +0000

Level Up Your NestJS App with RedisX

Diving into Redis with NestJS? Many of us start with ioredis for basic operations. But as your app grows, things get hairy. Caching, distributed locks, observability—suddenly, the simple setup isn't cutting it. This is where NestJS RedisX steps in. It's a toolkit that wraps up all those extra Redis features you need, neatly integrated into the NestJS framework.

What's Wrong with Just ioredis?

Honestly, nothing. If you're okay with juggling Redis connections, manual caching, and everything else by yourself. But let's face it, as projects scale, this manual handling turns into a maintenance nightmare. RedisX takes away that pain by offering a streamlined API that's baked right into NestJS. Less hassle, more productivity.

Getting Started with RedisX

Step 1: Install the Essentials

First things first, let's get RedisX into your project. Focus on the core package and the plugins you need. We'll deal with caching and locks here:

npm install @nestjs-redisx/core @nestjs-redisx/cache @nestjs-redisx/locks

Step 2: Set Up the Redis Module

Time to swap out your old ioredis setup. Configure the RedisModule in your AppModule like this:

import { Module } from '@nestjs/common';
import { ConfigModule, ConfigService } from '@nestjs/config';
import { RedisModule } from '@nestjs-redisx/core';
import { CachePlugin } from '@nestjs-redisx/cache';
import { LocksPlugin } from '@nestjs-redisx/locks';

@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),
    RedisModule.forRootAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      plugins: [
        CachePlugin.registerAsync({
          inject: [ConfigService],
          useFactory: (config: ConfigService) => ({
            defaultTtl: config.get('CACHE_TTL', 300),
          }),
        }),
        new LocksPlugin({ retryAttempts: 3 }),
      ],
      useFactory: (config: ConfigService) => ({
        clients: {
          type: 'single',
          host: config.get('REDIS_HOST', 'localhost'),
          port: config.get('REDIS_PORT', 6379),
        },
      }),
    }),
  ],
})
export class AppModule {}

Step 3: Transform Your Service Logic

Change your cache logic from ioredis commands to RedisX decorators. Here's a quick switch:

Before (ioredis):

async getUser(id: string): Promise<User> {
  const cached = await this.redis.get(`user:${id}`);
  if (cached) return JSON.parse(cached);
  const user = await this.userRepository.findById(id);
  await this.redis.setex(`user:${id}`, 3600, JSON.stringify(user));
  return user;
}

After (RedisX):

import { Injectable } from '@nestjs/common';
import { Cached } from '@nestjs-redisx/cache';

@Injectable()
export class UserService {
  @Cached({ key: 'user:{0}', ttl: 3600 })
  async getUser(id: string): Promise<User> {
    return this.userRepository.findById(id);
  }
}

Step 4: Handling Distributed Locks

Ditch the manual lock logic. Use RedisX's @WithLock decorator for a cleaner and safer approach.

Before (ioredis):

const lock = await this.redis.set(lockKey, uuid(), 'EX', 30, 'NX');
if (!lock) throw new Error('Lock acquisition failed');
try { await this.doWork(); }
finally { await this.redis.del(lockKey); }

After (RedisX):

import { WithLock } from '@nestjs-redisx/locks';

@WithLock({ key: 'resource:{0}', ttl: 5000 })
async secureResourceAccess(resourceId: string) {
  await this.doWork(resourceId);
}

Why Make the Switch?

RedisX isn't just a nice-to-have. It's packed with advanced features like L1+L2 caching, distributed locks, and more—all under one roof. Your codebase becomes cleaner, less error-prone, and ready for scale. Dive into the official docs for more.

Ready to take your NestJS app to the next level? RedisX is your friend. Give it a go.

Boost Your NestJS Observability with RedisX

Suren Krmoian — Fri, 27 Feb 2026 10:00:41 +0000

Observability is one of those things you can't ignore if you're managing modern applications. It's the secret sauce that gives developers a peek into how their systems are really performing. If you're working with NestJS and Redis, the RedisX toolkit is your new best friend for upping your observability game with Prometheus metrics and OpenTelemetry tracing.

Getting RedisX Rolling in Your NestJS App

Let's get down to business and set up RedisX for some serious observability in your NestJS app. First things first, you'll need to install a few packages. Fire up your terminal and run:

npm install @nestjs-redisx/core @nestjs-redisx/metrics @nestjs-redisx/tracing

Once that's sorted, it's time to tweak your AppModule. You'll want to add MetricsPlugin and TracingPlugin to get Prometheus metrics and OpenTelemetry tracing without breaking a sweat.

import { Module } from '@nestjs/common';
import { ConfigModule, ConfigService } from '@nestjs/config';
import { RedisModule } from '@nestjs-redisx/core';
import { MetricsPlugin } from '@nestjs-redisx/metrics';
import { TracingPlugin } from '@nestjs-redisx/tracing';

@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),
    RedisModule.forRootAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      plugins: [
        new MetricsPlugin({ enabled: true, exposeEndpoint: true }),
        new TracingPlugin({ serviceName: 'nestjs-app' }),
      ],
      useFactory: (config: ConfigService) => ({
        clients: {
          type: 'single',
          host: config.get('REDIS_HOST', 'localhost'),
          port: config.get('REDIS_PORT', 6379),
        },
      }),
    }),
  ],
})
export class AppModule {}

Prometheus Metrics: The Lowdown

With MetricsPlugin in place, your app now has a /metrics endpoint ready to roll. This little endpoint is a goldmine of info on Redis operations—think cache hits, misses, and lock contentions.

If you're using Prometheus, you need to set it up to scrape this endpoint. Your prometheus.yml should look something like this:

global:
  scrape_interval: 15s
scrape_configs:
  - job_name: 'nestjs-app'
    metrics_path: '/metrics'
    static_configs:
      - targets: ['localhost:3000']

OpenTelemetry Tracing: Going Deeper

TracingPlugin in RedisX uses OpenTelemetry to keep track of every Redis operation. It's like having a magnifying glass on every command—great for spotting performance bottlenecks.

Here's a quick example of how you might use custom spans in a NestJS service:

import { Injectable, Inject } from '@nestjs/common';
import { TRACING_SERVICE, ITracingService } from '@nestjs-redisx/tracing';

@Injectable()
export class UserService {
  constructor(@Inject(TRACING_SERVICE) private readonly tracing: ITracingService) {}

  async getUser(id: string): Promise<unknown> {
    return this.tracing.withSpan('user.get', async () => {
      this.tracing.setAttribute('user.id', id);
      const user = await this.userRepo.findById(id);
      this.tracing.addEvent('user.found', { 'user.email': user.email });
      return user;
    });
  }
}

Wrapping It Up

By bringing RedisX’s MetricsPlugin and TracingPlugin into your NestJS workflow, you're not just monitoring your app—you're setting it up for success. These tools give you the insights you need to keep things running smoothly and fix issues before they become problems.

Want more details on RedisX plugins? Check out the RedisX documentation.

Taming Cache Stampede in NestJS with RedisX

Suren Krmoian — Mon, 23 Feb 2026 10:00:31 +0000

Taming Cache Stampede in NestJS with RedisX

Cache stampede, or the thundering herd problem, is that pesky issue when a cache expires, and suddenly, your database gets bombarded by a swarm of requests. Not fun. In NestJS, there's a nifty way to tackle this using NestJS RedisX.

What's the Deal with Cache Stampede?

Imagine this: your app’s cache entry expires. Every request that comes in wants to hit the database at the same time. Chaos, right? The trick here is to make sure only one request actually goes through to the database, and the rest just chill until the first request updates the cache.

Enter NestJS RedisX

NestJS RedisX is like a Swiss Army knife for Redis in NestJS. One of its coolest features? Built-in cache stampede protection.

Setting It Up

Let's see how to set this up and save your database from overload.

Get the Packages First thing, install RedisX and the cache plugin:

   npm install @nestjs-redisx/core @nestjs-redisx/cache

Configure Redis in Your AppModule Use RedisModule.forRootAsync to set things up with async config (thanks to ConfigService):

   import { Module } from '@nestjs/common';
   import { ConfigModule, ConfigService } from '@nestjs/config';
   import { RedisModule } from '@nestjs-redisx/core';
   import { CachePlugin } from '@nestjs-redisx/cache';

   @Module({
     imports: [
       ConfigModule.forRoot({ isGlobal: true }),
       RedisModule.forRootAsync({
         imports: [ConfigModule],
         inject: [ConfigService],
         plugins: [
           CachePlugin.registerAsync({
             inject: [ConfigService],
             useFactory: (config: ConfigService) => ({
               l1: { enabled: true, maxSize: 1000, ttl: 60 },
               defaultTtl: config.get('CACHE_TTL', 300),
               stampede: { enabled: true },
             }),
           }),
         ],
         useFactory: (config: ConfigService) => ({
           clients: {
             host: config.get('REDIS_HOST', 'localhost'),
             port: config.get('REDIS_PORT', 6379),
           },
         }),
       }),
     ],
   })
   export class AppModule {}

Decorate Your Services with @Cached Now, slap the @Cached decorator on your service methods that fetch data:

   import { Injectable } from '@nestjs/common';
   import { Cached } from '@nestjs-redisx/cache';

   @Injectable()
   export class ProductService {
     @Cached({ key: 'product:{0}', ttl: 3600, stampede: { enabled: true } })
     async getProduct(id: string): Promise<Product> {
       return this.db.findProduct(id);
     }
   }

The Magic Behind It

With the @Cached decorator and the stampede option enabled, your app ensures that only one request hits the database. The rest wait their turn, and everyone gets their data once the cache is updated. It’s like a well-behaved queue at the supermarket checkout.

NestJS RedisX doesn't just handle cache stampedes. It's a full-on toolkit integrating Redis with features like distributed locks, rate limiting, and observability tools. Dive deeper into the official docs or check out the GitHub repo for more.

Redis in NestJS: The RedisX Solution You Didn't Know You Needed

Suren Krmoian — Sun, 22 Feb 2026 22:34:35 +0000

Redis in NestJS: The RedisX Solution You Didn't Know You Needed

Tired of wrangling with multiple libraries for Redis operations in your NestJS app? Meet NestJS RedisX. It’s the all-in-one toolkit for all your Redis needs — caching, locking, rate limiting, and more — without the hassle of multiple connections.

Why RedisX?

If you've been struggling with managing separate Redis connections for different functions, RedisX is your new best friend. It offers a modular approach where everything runs off a single Redis connection. That means less complexity and centralized configuration.

Plugin Power

RedisX is all about plugins. Install just what you need and keep things lean:

@nestjs-redisx/cache: L1+L2 caching with some nifty features like stampede protection.
@nestjs-redisx/locks: Distributed locks with auto-renewal.
@nestjs-redisx/rate-limit: Various strategies for rate limiting.
@nestjs-redisx/idempotency: Keep those requests idempotent.
@nestjs-redisx/streams: For those who love event-driven architectures.
@nestjs-redisx/metrics: Prometheus metrics, anyone?
@nestjs-redisx/tracing: OpenTelemetry tracing support.

Get Up and Running

Ready to dive in? Install the core package and any plugins you fancy:

npm install @nestjs-redisx/core @nestjs-redisx/cache @nestjs-redisx/locks

Then, wire it up in your AppModule:

import { Module } from '@nestjs/common';
import { ConfigModule, ConfigService } from '@nestjs/config';
import { RedisModule } from '@nestjs-redisx/core';
import { CachePlugin } from '@nestjs-redisx/cache';
import { LocksPlugin } from '@nestjs-redisx/locks';

@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),
    RedisModule.forRootAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      plugins: [
        CachePlugin.registerAsync({
          imports: [ConfigModule],
          inject: [ConfigService],
          useFactory: (config: ConfigService) => ({
            l1: { enabled: true, maxSize: 1000, ttl: 60 },
            defaultTtl: config.get('CACHE_TTL', 300),
          }),
        }),
        new LocksPlugin({ retryAttempts: 3, retryDelay: 200 }),
      ],
      useFactory: (config: ConfigService) => ({
        clients: {
          type: 'single',
          host: config.get('REDIS_HOST', 'localhost'),
          port: config.get('REDIS_PORT', 6379),
        },
      }),
    }),
  ],
})
export class AppModule {}

Wrapping It Up

RedisX is the toolkit that makes Redis integration a breeze in NestJS applications. No more juggling — just a clean, unified approach to Redis. Focus more on what you love: building cool features. For more insights, check out the official documentation and GitHub repository.

Moving from cache-manager to a Production-Grade Caching Layer in NestJS

Suren Krmoian — Thu, 19 Feb 2026 15:56:51 +0000

cache-manager is the default caching solution in NestJS. It works. It gets you started. And then, at some point, you hit a wall.

Maybe it's the moment you realize CacheInterceptor only works on controller methods, not service methods. Maybe it's when two pods simultaneously rebuild the same expensive cache entry after it expires. Maybe it's when you need to invalidate all caches related to a specific user and discover there's no built-in way to do tag-based invalidation.

This article walks through the specific limitations you'll hit with cache-manager in production and how to migrate to a caching layer that handles them.

Where cache-manager breaks down

1. Interceptors only work on controllers

NestJS's CacheInterceptor decorates HTTP endpoints:

@Controller('users')
@UseInterceptors(CacheInterceptor)
export class UserController {
  @Get(':id')
  @CacheTTL(300)
  async getUser(@Param('id') id: string) {
    return this.userService.findById(id);
  }
}

This works for the controller layer. But what about caching inside services? What about a ReportService.generateMonthlyReport() that's called by both an HTTP endpoint and a cron job?

// This does NOT work — CacheInterceptor requires HTTP context
@Injectable()
export class ReportService {
  @UseInterceptors(CacheInterceptor) // ← No effect on service methods
  async generateMonthlyReport(month: string) {
    // expensive computation...
  }
}

You end up manually calling cacheManager.get() and cacheManager.set() with boilerplate in every method.

2. No stampede protection

When a cached value expires, the next request triggers a cache miss and rebuilds the value. If 100 requests arrive during the rebuild, all 100 hit the database simultaneously. This is the cache stampede problem.

cache-manager has no built-in protection. You'd need to implement locking or request coalescing yourself.

3. Single-tier cache only

cache-manager stores values in one place. If you want in-memory caching for the hottest keys (avoiding Redis round-trips entirely) with Redis as a fallback for the long tail, you need to build that two-tier system manually.

4. No tag-based invalidation

An e-commerce app caches product listings, user carts, category pages, and search results. A product price changes. Which caches need invalidating?

With cache-manager, you either know every specific cache key to delete (brittle) or flush everything (wasteful). There's no way to say "invalidate everything tagged with product:123."

5. No stale-while-revalidate

Modern caching returns the stale value immediately while refreshing in the background. This keeps response times consistent even during cache rebuilds. cache-manager doesn't support this pattern.

Migration: step by step

Step 1: Replace the module registration

Before:

import { CacheModule } from '@nestjs/cache-manager';
import { redisStore } from 'cache-manager-redis-yet';

@Module({
  imports: [
    CacheModule.registerAsync({
      useFactory: async () => ({
        store: await redisStore({
          socket: {
            host: process.env.REDIS_HOST,
            port: parseInt(process.env.REDIS_PORT, 10),
          },
          password: process.env.REDIS_PASSWORD,
          ttl: 300000,
        }),
      }),
    }),
  ],
})
export class AppModule {}

After:

import { RedisModule } from '@nestjs-redisx/core';
import { CachePlugin } from '@nestjs-redisx/cache';

@Module({
  imports: [
    RedisModule.forRootAsync({
      useFactory: () => ({
        clients: {
          host: process.env.REDIS_HOST,
          port: parseInt(process.env.REDIS_PORT, 10),
          password: process.env.REDIS_PASSWORD,
        },
      }),
      plugins: [
        CachePlugin.registerAsync({
          useFactory: () => ({
            l1: { max: 1000, ttl: 30 },
            l2: { defaultTtl: 300 },
            antiStampede: true,
          }),
        }),
      ],
    }),
  ],
})
export class AppModule {}

You immediately get L1 (in-memory) + L2 (Redis) caching and stampede protection, without changing any application code yet.

Step 2: Replace manual cache calls with @Cached

Before:

@Injectable()
export class UserService {
  constructor(@Inject(CACHE_MANAGER) private cache: Cache) {}

  async getUser(id: string): Promise<User> {
    const cacheKey = `user:${id}`;
    const cached = await this.cache.get<User>(cacheKey);
    if (cached) return cached;

    const user = await this.userRepo.findById(id);
    await this.cache.set(cacheKey, user, 300000);
    return user;
  }
}

After:

import { Cached } from '@nestjs-redisx/cache';

@Injectable()
export class UserService {
  @Cached({ ttl: 300, tags: ['users'] })
  async getUser(id: string): Promise<User> {
    return this.userRepo.findById(id);
  }
}

The @Cached decorator handles the cache-aside pattern: check cache, return if hit, execute method if miss, store result, return. It works on any method in any @Injectable() class, not just controller endpoints.

The tags: ['users'] parameter enables tag-based invalidation later.

Step 3: Replace CacheInterceptor with @Cached

Before:

@Controller('users')
export class UserController {
  @Get(':id')
  @UseInterceptors(CacheInterceptor)
  @CacheTTL(300)
  async getUser(@Param('id') id: string) {
    return this.userService.findById(id);
  }
}

After — move caching to the service layer:

@Controller('users')
export class UserController {
  @Get(':id')
  async getUser(@Param('id') id: string) {
    return this.userService.getUser(id); // caching handled in service
  }
}

Now the same caching applies whether getUser is called from an HTTP request, a cron job, a queue worker, or another service.

Step 4: Add tag-based invalidation

import { CacheEvict } from '@nestjs-redisx/cache';

@Injectable()
export class UserService {
  @Cached({ ttl: 300, tags: (id: string) => [`users`, `user:${id}`] })
  async getUser(id: string): Promise<User> {
    return this.userRepo.findById(id);
  }

  @CacheEvict({ tags: (id: string) => [`user:${id}`] })
  async updateUser(id: string, data: UpdateUserDto): Promise<User> {
    return this.userRepo.update(id, data);
  }

  @CacheEvict({ tags: ['users'] })
  async importUsers(users: User[]): Promise<void> {
    await this.userRepo.bulkInsert(users);
    // This invalidates ALL user-related caches at once
  }
}

When updateUser('123') is called, everything tagged with user:123 is invalidated. When importUsers() is called, everything tagged with users is invalidated. No manual key management.

Step 5: Enable stale-while-revalidate

For endpoints where slightly stale data is acceptable but consistent response times are critical:

@Cached({
  ttl: 300,
  swr: 600, // Serve stale for up to 600s while refreshing
  tags: ['dashboard'],
})
async getDashboardData(): Promise<DashboardData> {
  // Expensive aggregation query
  return this.analyticsRepo.aggregate();
}

After 300 seconds, the cached value is "stale." The next request gets the stale value instantly (zero latency) while a background refresh fetches fresh data. The stale value is served for up to 600 seconds. This eliminates the latency spike that normally occurs when a popular cache entry expires.

What you gain

Feature	cache-manager	After migration
Controller caching	Yes	Yes
Service method caching	Manual	`@Cached` decorator
Stampede protection	No	Built-in
Two-tier (memory + Redis)	Manual	Built-in L1/L2
Tag-based invalidation	No	`@CacheEvict` with tags
Stale-while-revalidate	No	Built-in SWR
Cache metrics	No	Via MetricsPlugin

The migration can be done incrementally. Start with the module swap and stampede protection (zero code changes). Then migrate service methods one at a time from manual cache.get/set to @Cached. Add tags and SWR as you need them.

GitHub: https://github.com/nestjs-redisx/nestjs-redisx
Documentation: https://nestjs-redisx.dev