DEV Community: Suren Krmoian

How to Stop Cascading Failures with @nestjs-redisx/circuit-breaker

Suren Krmoian — Sat, 25 Jul 2026 08:26:24 +0000

Stop Cascading Failures Across Every Instance

Got a downstream dependency that's acting up — maybe a payment gateway, a search cluster, or some partner API? The knee-jerk reaction is to keep hammering it with requests. But here's the rub: each request sits there, waiting to time out, hogging a connection, and then failing anyway. Under heavy load, this is how one sluggish dependency can bring down your entire service — connection pools run dry, event loop latency shoots through the roof, and even the healthy endpoints start choking.

The circuit breaker pattern is your savior here. It fails fast, cutting the problem off at the knees. After a set number of failures, the breaker trips, and any following calls get an immediate answer — no timeouts, no held connections — giving the troubled dependency a breather.

@nestjs-redisx/circuit-breaker puts this pattern into action. But here's the twist: the breaker state is stored in Redis, shared across every instance of your app.

Why Distributed State Matters

Inline circuit breakers are per-instance, meaning if you've got ten pods, you've got ten independent breakers. Each one learns the failure lesson separately. Set the failure threshold to 5, and the dependency can absorb up to 50 failing requests before all breakers trip. Scale to fifty pods? That's 250.

And recovery? Just as chaotic. Each instance probes independently, so a recovering dependency might face fifty simultaneous probe requests instead of one. Enter Redis-backed state: all instances share a single circuit. Five failures trip the breaker for everyone, and when the cooldown ends, only a limited number of probes get through, not one per instance.

Installation

npm install @nestjs-redisx/core @nestjs-redisx/circuit-breaker ioredis

Configuration

import { Module } from '@nestjs/common';
import { ConfigModule, ConfigService } from '@nestjs/config';
import { RedisModule } from '@nestjs-redisx/core';
import { CircuitBreakerPlugin } from '@nestjs-redisx/circuit-breaker';

@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),
    RedisModule.forRootAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      plugins: [
        CircuitBreakerPlugin.registerAsync({
          imports: [ConfigModule],
          inject: [ConfigService],
          useFactory: (config: ConfigService) => ({
            failureThreshold: config.get('CB_FAILURE_THRESHOLD', 5),
            windowMs: config.get('CB_WINDOW_MS', 10000),
            openDurationMs: config.get('CB_OPEN_DURATION_MS', 30000),
          }),
        }),
      ],
      useFactory: (config: ConfigService) => ({
        clients: {
          type: 'single',
          host: config.get('REDIS_HOST', 'localhost'),
          port: config.get('REDIS_PORT', 6379),
        },
      }),
    }),
  ],
})
export class AppModule {}

Here, three parameters set the policy: trip the breaker after failureThreshold failures within a windowMs rolling window, and stay open for openDurationMs before allowing probe traffic.

The Decorator

import { Injectable } from '@nestjs/common';
import { WithCircuitBreaker } from '@nestjs-redisx/circuit-breaker';

@Injectable()
export class PaymentsService {
  @WithCircuitBreaker({
    key: 'stripe',
    fallback: () => ({ queued: true }),
  })
  async charge(dto: ChargeDto) {
    return this.stripe.charge(dto);
  }
}

When the circuit is open, charge() doesn't even try to hit Stripe. It immediately returns the fallback, queuing the payment for a retry rather than outright failing the user's request.

The decorator is proxy-based, meaning it works on any @Injectable() method without needing a specific base class or manual service injection. Keys can be interpolated from method arguments, letting you scope a breaker per tenant, region, or partner:

@Injectable()
export class SearchService {
  @WithCircuitBreaker({ key: 'search:{0}', onOpen: 'skip' })
  async queryRegion(region: string, term: string) {
    return this.elastic.search(region, term);
  }
}

Each region has its own circuit. So, a failing eu-west cluster doesn't stop us-east queries. The onOpen: 'skip' option returns undefined instead of throwing — good for optional calls where a missing result is fine, but an error isn't.

The Programmatic API

For those cases where a decorator just won't cut it — dynamic keys, conditional wrapping, or code outside the DI graph — CircuitBreakerService provides the same tools directly:

import { Injectable, Inject } from '@nestjs/common';
import {
  CIRCUIT_BREAKER_SERVICE,
  type ICircuitBreakerService,
} from '@nestjs-redisx/circuit-breaker';

@Injectable()
export class WebhookDispatcher {
  constructor(
    @Inject(CIRCUIT_BREAKER_SERVICE)
    private readonly breaker: ICircuitBreakerService,
  ) {}

  async dispatch(endpoint: string, payload: unknown) {
    return this.breaker.execute(
      `webhook:${endpoint}`,
      () => this.http.post(endpoint, payload),
      { fallback: () => this.deadLetter.push(endpoint, payload) },
    );
  }
}

Besides execute(), the service offers recordSuccess and recordFailure for manual accounting. Decide what counts as a failure — maybe a 503 should trip the breaker, but a 404 shouldn't.

The State Machine

The breaker has three classic states:

Closed is normal. Calls go through, failures pile up in a rolling window. Hit the count within windowMs, and the breaker trips.

Open fails fast. Calls return the fallback (or throw, or skip) without hitting the dependency. This protects your service and the struggling dependency — no retry storm, no held connections. After openDurationMs, the breaker moves to half-open.

Half-open tests the waters. A limited number of calls go through to see if the dependency is back on its feet. Success closes the circuit; failure reopens it for another full cooldown. The cap is across all instances, so a recovering service gets just a few probes.

The Zombie Probe Problem

Half-open probes can create a subtle failure mode. A probe slot is claimed when a call is allowed through and released when the outcome is recorded. But if the process crashes mid-call? The slot is never released. With a small probe cap, the circuit might stay half-open indefinitely.

The plugin handles this with probeTimeoutMs: a probe that doesn't get its outcome recorded loses its slot after a timeout, freeing it for another instance.

When the State Store Itself Fails

A distributed breaker depends on something too. If Redis is unreachable, what should happen to the calls the breaker should protect?

There are two defensible answers, and the plugin lets you choose. Fail-open allows calls when the breaker state is unavailable — you lose protection but keep availability. Fail-closed rejects calls — you lose availability but ensure the breaker's protection is never absent.

Testing the Policy

Circuit breaker logic is tricky to test. It's time-based, so tests need fake timers. It's stateful, so tests need isolation. It's distributed, so tests want a Redis instance. The result? Often a slow, flaky suite.

This plugin separates policy from I/O. CircuitBreakerState is a pure state machine: no network calls, no Date.now(). Every time-based method takes an explicit now as an argument, making it fully deterministic and testable:

import { CircuitBreakerState } from '@nestjs-redisx/circuit-breaker';

it('trips after threshold failures inside the window', () => {
  const state = new CircuitBreakerState({
    failureThreshold: 3,
    windowMs: 10_000,
    openDurationMs: 30_000,
  });

  const t0 = 1_000_000;
  state.recordFailure(t0);
  state.recordFailure(t0 + 1_000);
  state.recordFailure(t0 + 2_000);

  expect(state.getStatus(t0 + 2_000)).toBe('open');
  expect(state.getStatus(t0 + 40_000)).toBe('half-open');
});

No fake timers, no waiting, no flakiness. Time is just numbers here.

For integration — decorator behavior, Redis coordination, Lua script correctness — the plugin uses @nestjs-redisx/testing, an in-memory driver. You can test the real code path without a Redis process:

import { Test } from '@nestjs/testing';
import { RedisTestingModule } from '@nestjs-redisx/testing';
import {
  CircuitBreakerPlugin,
  CIRCUIT_BREAKER_SERVICE,
  type ICircuitBreakerService,
} from '@nestjs-redisx/circuit-breaker';

it('fails fast once the circuit is open', async () => {
  const module = await Test.createTestingModule({
    imports: [
      RedisTestingModule.forRoot({
        plugins: [
          new CircuitBreakerPlugin({
            failureThreshold: 2,
            windowMs: 10_000,
            openDurationMs: 30_000,
          }),
        ],
      }),
    ],
  }).compile();
  await module.init();

  const breaker = module.get<ICircuitBreakerService>(CIRCUIT_BREAKER_SERVICE);
  const failing = async () => {
    throw new Error('upstream down');
  };

  await expect(breaker.execute('svc', failing)).rejects.toThrow();
  await expect(breaker.execute('svc', failing)).rejects.toThrow();

  let called = false;
  const result = await breaker.execute(
    'svc',
    async () => ((called = true), 'live'),
    { fallback: () => 'fallback' },
  );

  expect(result).toBe('fallback');
  expect(called).toBe(false);
});

And there you have it. @nestjs-redisx/circuit-breaker shares state through Redis, with atomic Lua transitions, providing a decorator and a programmatic API. It handles those tricky operational edge cases and keeps the policy layer pure for easy testing.

For a deep dive, check out the full reference or the GitHub repo.

Turbocharging Redis Performance in NestJS with RedisX

Suren Krmoian — Sat, 25 Jul 2026 08:20:36 +0000

Getting the most out of Redis in your NestJS applications is all about fine-tuning performance. RedisX is a toolkit that makes integrating Redis into NestJS a breeze. Let's break down how you can beef up performance with configuration, monitoring, and some smart practices.

Configuration Tips

First things first: when you're setting up Redis, you want it to play nice with your NestJS config. Enter forRootAsync(). It's like the swiss army knife for async config using ConfigService. This keeps things flexible and tidy. Want to shave off some latency? Think about a two-tier caching system—L1 in-memory and L2 Redis. Use CachePlugin.registerAsync() if you're aiming for stampede protection and Stale-While-Revalidate (SWR) patterns. Check our previous SWR post if you need a refresher.

Here's a quick peek at how you might set that up:

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

Monitoring Techniques

Now, let's talk visibility. You can't fix what you can't see, right? That's where MetricsPlugin and TracingPlugin come into play. They expose Prometheus metrics and OpenTelemetry traces right from your app. You'll get a clear view of cache hit rates, lock contention, you name it.

Prometheus Metrics: Set up a /metrics endpoint and you're off to the races. Track stuff like redisx_cache_hits_total and redisx_lock_acquired_total. It's like having x-ray vision for your cache performance.
OpenTelemetry Tracing: This is your go-to for tracking Redis command lifecycles and seeing how they affect app performance. Detailed insights, right at your fingertips.

Best Practices

Use Connection Pooling: Share a single Redis connection across all plugins. It's like carpooling for connections—saves resources and keeps things simple.
Leverage Decorators: Decorators like @Cached, @WithLock, and @RateLimit cut down on boilerplate and centralize config. Less code, more efficiency.
Optimize Key Management: Stick to smart key naming and expiration strategies. Avoid those nasty key collisions and keep your cache effective.
Monitor and Adjust TTLs: TTLs aren't set-it-and-forget-it. Regularly tweak them based on access patterns. Balance is key—hit rates vs. data freshness.

These tuning techniques, combined with RedisX's capabilities, can seriously amp up your NestJS app's performance and scalability. Dive into the RedisX docs for more on plugin configs that fit your app just right.

Harness Redis Power in NestJS with RedisX

Suren Krmoian — Sat, 25 Jul 2026 08:20:14 +0000

Supercharge Your NestJS Apps with RedisX

If you've been fiddling with Redis in your NestJS applications, it's time to look beyond just basic caching. NestJS RedisX is a game-changer, bringing a suite of advanced Redis functionalities right to your codebase. Think distributed locks, rate limiting, idempotency, and more—all without the hassle of juggling multiple libraries.

RedisX Modules: All-in-One Toolkit

NestJS RedisX is like a Swiss Army knife for Redis in your backend. It wraps a bunch of Redis functionalities into a single, neat package. No more chaos from managing multiple Redis connections. It's all modular, so you only plug in what you need. Let's dive into some of its standout features.

Caching: Beyond Key-Value

Caching with RedisX is not your average key-value store. With both in-memory (L1) and Redis (L2) caching tiers, it supports advanced strategies like cache stampede protection and the Stale-While-Revalidate pattern. This setup isn't just about reducing database load; it makes your app snappier.

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

RedisModule.forRootAsync({
  plugins: [
    CachePlugin.registerAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      useFactory: (config: ConfigService) => ({
        l1: { enabled: true, maxSize: 1000, ttl: 60 },
        defaultTtl: config.get('CACHE_TTL', 300),
        stampede: { enabled: true },
        swr: { enabled: true },
      }),
    }),
  ],
});

Distributed Locks: Keep it Synchronized

Concurrency issues? RedisX's distributed locking mechanism has got you covered. Whether it's inventory management or any other area where simultaneous access is a concern, this tool is your friend. Decorators and services make lock management a breeze.

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

@Injectable()
export class InventoryService {
  @WithLock({ key: 'inventory:{0}', ttl: 5000 })
  async adjustInventory(productId: string, change: number): Promise<void> {
    // Logic to adjust inventory
  }
}

Rate Limiting: Fair and Square

Public APIs can be abused if not properly managed. RedisX's Rate Limit Plugin provides several strategies for keeping request rates in check, like fixed and sliding window algorithms. A must-have for any public-facing API.

import { RateLimit } from '@nestjs-redisx/rate-limit';

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

Idempotency: No Double Charges

Especially in payment processing, duplicate requests can lead to headaches. RedisX's Idempotency Plugin ensures operations like these are idempotent, preventing unwanted duplicate charges.

import { Idempotent } from '@nestjs-redisx/idempotency';

@Controller('payments')
export class PaymentsController {
  @Post()
  @Idempotent()
  async createPayment(@Body() dto: CreatePaymentDto) {
    // Payment processing logic
  }
}

Get the Most Out of RedisX

Async Configuration: Use forRootAsync() for loading configurations dynamically using services and environment variables. It's the way to go.
Tailored Plugin Settings: Each plugin can be fine-tuned to fit your app's unique needs.
Single Connection: All plugins share one Redis connection. Less hassle, better performance.

By leveraging RedisX in your NestJS projects, you simplify your architecture and maximize Redis's power. No more messing around with multiple libraries; RedisX brings you a tidy, powerful setup.

Exploring OpenTelemetry Tracing in NestJS with RedisX

Suren Krmoian — Tue, 23 Jun 2026 10:00:04 +0000

In today's complex application landscapes, observability is essential, providing insights into application performance and system behavior. OpenTelemetry has emerged as a robust standard for distributed tracing, enabling developers to capture detailed telemetry data across diverse systems. When combined with the power of NestJS and RedisX, OpenTelemetry tracing can provide unparalleled visibility into Redis operations and application performance.

Why OpenTelemetry?

OpenTelemetry offers a vendor-agnostic way to collect telemetry data, such as traces and metrics, from applications. It supports various backends like Jaeger, Zipkin, and Prometheus, making it a versatile choice for observability in distributed systems.

RedisX and OpenTelemetry

NestJS RedisX is a modular toolkit designed to integrate seamlessly with Redis, offering a suite of plugins for caching, locking, rate limiting, and more. The Tracing Plugin within RedisX leverages OpenTelemetry to trace every Redis command executed through the toolkit, providing insights into operations like cache hits/misses, lock acquisitions, and stream processing.

Setting Up OpenTelemetry Tracing in NestJS with RedisX

To integrate OpenTelemetry tracing in your NestJS application using RedisX, you need to follow these steps:

Install Necessary Packages: Install the core and tracing packages:

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

Configure the Tracing Plugin: Use TracingPlugin.registerAsync() for configuration, which allows dynamic setup with the ConfigService.

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

   @Module({
     imports: [
       ConfigModule.forRoot({ isGlobal: true }),
       RedisModule.forRootAsync({
         imports: [ConfigModule],
         inject: [ConfigService],
         plugins: [
           TracingPlugin.registerAsync({
             useFactory: (config: ConfigService) => ({
               enabled: config.get('TRACING_ENABLED', true),
               serviceName: config.get('SERVICE_NAME', 'my-service'),
               exporter: {
                 type: 'otlp',
                 endpoint: config.get('OTLP_ENDPOINT', 'http://localhost:4318'),
               },
               sampling: {
                 strategy: 'ratio',
                 ratio: config.get('TRACING_SAMPLE_RATIO', 1.0),
               },
             }),
             inject: [ConfigService],
           }),
         ],
         useFactory: (config: ConfigService) => ({
           clients: {
             host: config.get('REDIS_HOST', 'localhost'),
             port: config.get('REDIS_PORT', 6379),
           },
         }),
       }),
     ],
   })
   export class AppModule {}

Implement Tracing in Services: With RedisX, tracing is automatically applied to all Redis operations. However, you can also create custom spans for more granular insights.

   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;
       });
     }
   }

Benefits of Tracing with RedisX

Detailed Insights: Every Redis command is traced, providing a clear picture of how data flows through your application.
Performance Monitoring: Identify bottlenecks and optimize Redis usage by analyzing trace data.
Error Diagnosis: Quickly pinpoint where errors occur in the Redis interaction chain.
Seamless Integration: The Tracing Plugin integrates smoothly with other RedisX plugins, sharing the same Redis connection.

Integrating OpenTelemetry tracing with NestJS and RedisX will not only enhance your observability but also empower you to make data-driven decisions to optimize application performance. With the detailed insights that tracing provides, teams can improve system reliability and user experience, making it an indispensable part of modern application development.
nestjs redis tracing

Optimizing Redis Key Management with NestJS RedisX

Suren Krmoian — Tue, 23 Jun 2026 05:11:18 +0000

Let's talk about managing Redis keys in your NestJS apps. Yeah, it's crucial for performance and reliability. If you're using NestJS RedisX, you're in luck. This modular toolkit can seriously simplify your Redis key management. So, what are we covering? Key naming conventions, expiration strategies, and cache coherence. Let's dive in.

Key Naming Conventions

Key naming might sound boring, but it's super important for keeping your Redis database neat and tidy. With NestJS RedisX, the trick is to use meaningful and structured names. A colon (:) makes for a great separator. It helps you create hierarchies in your keys. Something like user:123:profile works well, where 123 is the user ID. This approach is a lifesaver for operations like invalidating related keys or just plain debugging.

And here's a neat trick: use placeholders like {0} or {fieldName} in your key templates. This lets you inject method arguments right into the key names. Handy, right? Especially when you're using decorators like @Cached — they automatically derive keys from method parameters.

Expiration Strategies

Next up, expiration strategies. You don't want stale data hanging around forever. That's where setting the right expiration times for your Redis keys comes in. NestJS RedisX makes this easy with the ttl (time-to-live) option in decorators like @Cached. Set it, forget it, and let the keys disappear after a set time.

Say you want to cache a user's data for an hour. Use something like @Cached({ key: 'user:{0}:data', ttl: 3600 }). Adjust the TTL based on how often your data changes. Less frequent updates? Go for a longer TTL. Rapid changes? Keep it short.

Maintaining Cache Coherence

Cache coherence, sounds fancy, right? It's all about keeping your cache in sync with the data store. NestJS RedisX offers tag-based invalidation. This is a powerful way to keep things coherent. Tag your cache entries, and when the underlying data changes, you can invalidate them all at once.

Imagine caching a user's profile and order history. Tag them with user:123. When the data updates, just invalidate all related cache entries using this.cache.invalidateByTags(['user:123']). This helps avoid serving outdated info.

Practical Example

Let's think about a multi-tenant app. Each tenant has isolated caches. This prevents data leakage and ensures fairness in resources. By sticking to consistent key naming and tagging, you optimize these caches. It cuts down the risk of cache stampedes and boosts hit rates.

Wrapping Up

So, there you have it. Using NestJS RedisX for managing Redis keys can really boost your app's performance. Structured key names, smart expiration, and cache coherence through tagging — they all add up to a more efficient caching layer. Want more? Check out our series on RedisX for topics like Stale-While-Revalidate patterns and Redis Streams.

Boosting Observability in NestJS with RedisX Metrics

Suren Krmoian — Sat, 13 Jun 2026 09:35:18 +0000

Observability isn't just a buzzword; it's a necessity, especially when diving into distributed systems. If you're using NestJS, you might want to take a look at RedisX. It's a modular toolkit that can boost the observability of your applications. A standout feature? The Metrics Plugin. It meshes well with Prometheus, delivering insights into Redis operations in your NestJS setup.

Getting RedisX Metrics Rolling in NestJS

So, first things first. To harness the power of RedisX Metrics, you need to set up your NestJS app with RedisX. This means installing some packages and configuring the RedisModule with the MetricsPlugin.

Hit your terminal and run:

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

Now, let's tweak your AppModule. You want it to use RedisModule with MetricsPlugin:

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

@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),
    RedisModule.forRootAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      plugins: [
        new MetricsPlugin({
          prefix: 'redisx_',
          endpoint: '/metrics',
          defaultLabels: { service: 'my-service' }
        })
      ],
      useFactory: (config: ConfigService) => ({
        clients: {
          host: config.get('REDIS_HOST', 'localhost'),
          port: config.get('REDIS_PORT', 6379),
        },
      }),
    }),
  ],
})
export class AppModule {}

Prometheus Metrics: What You Get

With MetricsPlugin set up, your app now exposes a /metrics endpoint. Prometheus can scrape this endpoint, dishing out detailed metrics about your Redis operations. Here's a snapshot of what you get:

redisx_cache_hits_total: Tracks total cache hits.
redisx_lock_acquired_total: Total locks acquired.
redisx_redis_commands_total: Total Redis commands run.

Making Prometheus Work for You

To get those insights, set up Prometheus to scrape your /metrics endpoint. Check your prometheus.yml and add a scrape config like this:

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

This ensures Prometheus gathers metrics from your NestJS app, helping you monitor Redis interactions closely.

Insights: What to Do Next?

With Prometheus grabbing your metrics, visualize and analyze them with Grafana or similar tools. This setup helps you see Redis usage patterns, spot bottlenecks, and fine-tune your app's performance.

Using NestJS RedisX's MetricsPlugin isn't just about plugging in Prometheus metrics. It's about getting a full view of your Redis operations right out of the box. As you grow and scale, these insights will be key to keeping your systems running smoothly.

For more, check the NestJS RedisX Metrics documentation.

Mastering Redis Streams and DLQ in NestJS with RedisX

Suren Krmoian — Fri, 22 May 2026 07:05:15 +0000

Using Redis Streams in NestJS RedisX can be a game changer for anyone building event-driven systems. Today, let's dig into consumer groups and dead letter queues (DLQ) — two features that can really up your game in creating resilient architectures.

Redis Streams: The Basics

Redis Streams let you handle messages in a scalable way. The cool part? With consumer groups, you can have multiple service instances share the workload. So, each message goes to just one instance in the group. Perfect for load balancing and keeping your services running smoothly.

Getting Hands-On with Consumer Groups

Let's look at how easy it is to set up a consumer group in NestJS RedisX. With the @StreamConsumer decorator, you can define a consumer that listens to a specific stream and group:

import { Injectable } from '@nestjs/common';
import { StreamConsumer, IStreamMessage } from '@nestjs-redisx/streams';

@Injectable()
export class OrderProcessor {
  @StreamConsumer({
    stream: 'orders',
    group: 'order-processors',
    batchSize: 10,
  })
  async handleOrder(message: IStreamMessage<OrderEvent>): Promise<void> {
    const { orderId } = message.data;
    try {
      await this.fulfillmentService.process(orderId);
      await message.ack();
    } catch (error) {
      await message.reject(error);
    }
  }
}

Tackling Dead Letter Queues (DLQ)

Now, let's talk about DLQs. They're essential for dealing with message failures. If a message can't be processed after a few tries, you don't want it disappearing into the void. A DLQ ensures these messages are stored for review later — crucial for troubleshooting and making sure nothing slips through the cracks.

Here's how easy it is to enable DLQ in NestJS RedisX:

new StreamsPlugin({
  consumer: { batchSize: 10, maxRetries: 3 },
  dlq: { enabled: true },
})

Building Resilient Systems

With Redis Streams, consumer groups, and DLQ, you're well on your way to building systems that are both scalable and fault-tolerant. RedisX takes care of the heavy lifting, letting you zero in on your business logic.

For those hungry for more, it might be worth checking how these patterns play with other RedisX goodies like caching, idempotency, and tracing. All these pieces fit together to form a robust event-driven architecture.

Dive into the documentation for deeper insights on configuration and advanced usage. Want more? Check out our previous posts on Redis Sentinel and Cache Isolation for tips on building scalable applications with RedisX. nestjs redis streams

Implementing Idempotency with NestJS RedisX: A Practical Guide

Suren Krmoian — Tue, 12 May 2026 10:00:19 +0000

Handling duplicate requests in APIs, especially in payment systems, is a headache. NestJS RedisX offers a neat way to tackle this with its Idempotency Plugin. Let’s dig into how you can set this up.

Getting Started with Idempotency

First things first, install the necessary packages. You'll need both the core and idempotency packages of NestJS RedisX:

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

Configuring the Module

To make the Idempotency Plugin work its magic, you need to configure it in your main module. This setup ensures that the plugin is ready to catch any duplicate requests globally.

import { Module } from '@nestjs/common';
import { ConfigModule, ConfigService } from '@nestjs/config';
import { RedisModule } from '@nestjs-redisx/core';
import { IdempotencyPlugin } from '@nestjs-redisx/idempotency';
import { APP_INTERCEPTOR } from '@nestjs/core';
import { IdempotencyInterceptor } from '@nestjs-redisx/idempotency';

@Module({
  imports: [
    ConfigModule.forRoot(),
    RedisModule.forRootAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      plugins: [
        IdempotencyPlugin.registerAsync({
          imports: [ConfigModule],
          inject: [ConfigService],
          useFactory: (config: ConfigService) => ({
            defaultTtl: 86400, // 24 hours
            headerName: 'Idempotency-Key',
          }),
        }),
      ],
      useFactory: (config: ConfigService) => ({
        clients: {
          host: config.get('REDIS_HOST', 'localhost'),
          port: config.get('REDIS_PORT', 6379),
        },
      }),
    }),
  ],
  providers: [
    { provide: APP_INTERCEPTOR, useClass: IdempotencyInterceptor },
  ],
})
export class AppModule {}

Decorating Your Endpoints

Once your module is good to go, use the @Idempotent decorator on your endpoints. This ensures that each request is uniquely processed based on the Idempotency-Key.

import { Controller, Post, Body } from '@nestjs/common';
import { Idempotent } from '@nestjs-redisx/idempotency';

@Controller('payments')
export class PaymentsController {
  constructor(private readonly paymentService: PaymentService) {}

  @Post()
  @Idempotent()
  async createPayment(@Body() dto: CreatePaymentDto) {
    return this.paymentService.process(dto);
  }
}

Behind the Scenes

Here’s the lowdown: the Idempotency Plugin checks each request’s Idempotency-Key. If it’s seen the key before, it serves the cached result. No re-processing, no fuss.

Body Fingerprinting: It goes a step further by ensuring the request body’s fingerprint matches the key. This prevents using the same key for different data.
Concurrent Handling: If multiple requests with the same key pop up, the plugin handles them in sequence, avoiding any duplication.

Incorporating an idempotency layer using NestJS RedisX is pretty straightforward. It's a solid way to dodge duplicate processing in sensitive areas like payments. Want to dive deeper? Check out the official documentation.

Speed Up Your NestJS App with SWR Caching and RedisX

Suren Krmoian — Tue, 05 May 2026 10:00:26 +0000

Let's talk about something cool: Stale-While-Revalidate (SWR) caching. Imagine your app serves up slightly outdated data right away, while quietly updating it in the background. This means users get speedy responses without waiting for fresh data to load. Sweet, right? So, how do we get this running in a NestJS app? Meet RedisX.

Why Choose SWR?

Sometimes you need both speed and fresh data. SWR gives you that balance. Users get data fast, while your system updates in the background. Perfect for long data fetches, like big datasets or slow APIs.

Getting SWR Rolling with NestJS and RedisX

Ready to dive into setting up SWR? Here's how you can do it in a NestJS app using RedisX.

Step 1: Install Everything

First things first, install the necessary packages. Fire up your terminal:

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

Step 2: Configure AppModule

Time to set up your AppModule. We'll hook in the Redis module and smuggle in the Cache plugin with SWR enabled. Use forRootAsync() to make the magic happen with NestJS's dependency injection.

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),
            swr: { enabled: true, maxStale: 3600 },
          }),
        }),
      ],
      useFactory: (config: ConfigService) => ({
        clients: {
          type: 'single',
          host: config.get('REDIS_HOST', 'localhost'),
          port: config.get('REDIS_PORT', 6379),
        },
      }),
    }),
  ],
})
export class AppModule {}

Step 3: Use the @Cached Decorator

Here's where the magic happens. Use the @Cached decorator to slap caching onto your service methods. It'll let you define keys, TTLs, and SWR settings for each method.

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

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

In this setup, getProduct will serve stale data if it's there and refresh it in the background. Seamless for the user.

Why RedisX Rocks for SWR

RedisX makes SWR easy with its plugin system that uses just one Redis connection. Less overhead, more features. You get L1+L2 caching, tag-based invalidation, and more.

Performance Boost: Serve data instantly from the cache.
User Happiness: Less waiting for fresh data.
Simple Setup: Async support makes configuration a breeze.

Wrapping It Up

Setting up SWR in your NestJS app with RedisX is a breeze and super beneficial. Your apps stay fast and data stays fresh. Want to dive deeper? Check out the NestJS RedisX documentation.

By using RedisX, your NestJS apps don't just get faster—they become more robust and scalable. Redis magic at your fingertips.

Effortless Redis Sentinel Setup in NestJS with RedisX

Suren Krmoian — Tue, 21 Apr 2026 22:43:19 +0000

Redis Sentinel is no joke when it comes to keeping your Redis instances highly available. Hook it up with NestJS via RedisX, and you've got a streamlined, powerful setup.

Setting Up Redis Sentinel in NestJS with RedisX

Getting Redis Sentinel up and running with NestJS doesn't have to be rocket science. First, make sure your Redis environment has a Sentinel setup. You’ll need at least three Sentinel instances for a proper quorum and failover.

Step 1: Install Necessary Packages

Let's start by installing some packages. Open up your terminal and run:

npm install @nestjs-redisx/core ioredis

Boom. Now you have the core module and the ioredis driver, which plays nicely with Redis Sentinel.

Step 2: Sentinel Configuration

Time to configure. Head over to your AppModule in your NestJS app and set up RedisModule to use Sentinel:

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

@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),
    RedisModule.forRootAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      useFactory: (config: ConfigService) => ({
        clients: {
          type: 'sentinel',
          sentinels: [
            { host: config.get('SENTINEL_HOST1'), port: config.get('SENTINEL_PORT1') },
            { host: config.get('SENTINEL_HOST2'), port: config.get('SENTINEL_PORT2') },
            { host: config.get('SENTINEL_HOST3'), port: config.get('SENTINEL_PORT3') },
          ],
          name: config.get('SENTINEL_MASTER_NAME'),
        },
      }),
    }),
  ],
})
export class AppModule {}

Don’t forget to replace SENTINEL_HOST and SENTINEL_PORT with the actual details of your Sentinel instances.

Step 3: Why Use Redis Sentinel with RedisX?

Automatic Failover: If your master server bites the dust, Sentinel steps in, electing a new one without missing a beat.
Monitoring: Keeps an eye on your Redis instance. If something goes south, you'll know.
Simplified Setup: RedisX brings simplicity to Sentinel configurations, centralizing everything. Less hassle, more uptime.

RedisX Simplification

RedisX’s plugin architecture means everything—Sentinel included—lives under one roof. This keeps things neat, especially if you’re juggling multiple Redis setups.

Wrapping Up

There you have it. By setting up Redis Sentinel with NestJS via RedisX, you secure a reliable, high-availability Redis setup. It’s easy to manage and scales with your needs. Dive deeper into the NestJS RedisX documentation to explore more.

For specific details on configuring Redis Sentinel in NestJS, check out the NestJS Redis sentinel configuration.

NestJS RedisX: The Journey So Far

Suren Krmoian — Sat, 18 Apr 2026 09:08:48 +0000

NestJS RedisX: The Journey So Far

NestJS RedisX has been quite the story in the developer circles. Right from its launch, it’s been picking up steam on GitHub. Stars are rolling in, issues are being tackled head-on, and pull requests? They’re getting the attention they deserve. It’s like watching a community spring up around a new idea.

Why NestJS RedisX?

For those knee-deep in Redis and NestJS, NestJS RedisX is turning into a real game-changer. Handling enterprise-level challenges has never been more streamlined. The buzz and backing from the community? Honestly, it’s been a pleasant surprise. It’s this kind of energy that fuels us to keep improving.

What's Next?

We’ve got big plans. Our roadmap is packed with features and improvements that’ll push NestJS RedisX even further. The community’s energy is our battery pack, helping us find the time and resources to keep innovating.

How Can You Help?

Enjoying NestJS RedisX? Do us a favor and drop a star on GitHub. It’s a small gesture but means the world to us. It’s what keeps us going and helps us deliver even better solutions.

Become part of the movement. Contribute, lend a hand, and together, let’s shape the future of Redis tooling in NestJS. Every bit of support makes a difference.

Check it out on GitHub: nestjs-redisx/nestjs-redisx

NestJS RedisX: развитие и планы будущего

Suren Krmoian — Sat, 18 Apr 2026 09:06:05 +0000

Что нового в NestJS RedisX?

NestJS RedisX привлекает внимание разработчиков, и это не просто так. С момента запуска на GitHub проект набирает популярность: звёзды растут, проблемы решаются оперативно, а pull-реквесты активно рассматриваются и мёрджатся. Круто видеть, как формируется сообщество вокруг этого проекта!

Почему NestJS RedisX?

Для тех, кто углубляется в Redis и NestJS, RedisX становится незаменимым инструментом для решения задач на уровне предприятия. Положительные отзывы и поддержка сообщества просто поражают и вдохновляют на дальнейшую работу над улучшением инструментария.

Планы на будущее

У нас амбициозные планы: новые фичи и улучшения в пути. Энергия сообщества подстёгивает нас находить время и ресурсы для расширения возможностей NestJS RedisX.

Как вы можете помочь?

Если вам нравится использовать NestJS RedisX, поддержите нас звёздочкой на GitHub. Ваша поддержка бесценна и мотивирует нас создавать ещё более надёжные решения.

Присоединяйтесь, вносите свой вклад и помогите нам формировать будущее инструментов Redis в NestJS. Всякая поддержка важна, и вместе мы можем достичь многого.

Проверьте проект на GitHub: nestjs-redisx/nestjs-redisx