Redis

High-performance messaging with Redis using Nimbus

The Nimbus Redis transport uses Redis Lists for queues and Pub/Sub for topics, delivering sub-millisecond latency and 10,000+ messages/second. It’s a great fit for internal microservice communication, background job processing, and real-time event distribution where you want high throughput and simple setup.

Redis Pub/Sub doesn’t persist messages. Events published with no active subscribers are lost. For guaranteed event delivery, consider Azure Service Bus.

Installation

dotnet add package Nimbus.Redis

Quick Start

Run Redis

docker run -d -p 6379:6379 redis:latest

Configure Nimbus

using Nimbus;
using Nimbus.Configuration;
using Nimbus.Transports.Redis;

var bus = new BusBuilder()
    .Configure()
    .WithNames("OrderService", Environment.MachineName)
    .WithTransport(new RedisTransportConfiguration()
        .WithConnectionString("localhost:6379"))
    .WithTypesFrom(typeProvider)
    .WithAutofacDefaults(container)
    .Build();

await bus.Start();

Common connection string options:

// With password
.WithConnectionString("localhost:6379,password=your_redis_password")

// SSL (e.g. Azure Cache for Redis)
.WithConnectionString("your-cache.redis.cache.windows.net:6380,password=...,ssl=true,abortConnect=false")

// Redis Sentinel
.WithConnectionString("sentinel1:26379,sentinel2:26379,sentinel3:26379,serviceName=mymaster")

Idle Subscription Cleanup

Every event subscriber gets its own per-instance queue in Redis. To stop orphaned queues piling up when an instance restarts or crashes without unsubscribing, each subscription heartbeats while its instance is running and is deleted if that heartbeat lapses:

var bus = new BusBuilder()
    .Configure()
    .WithNames("OrderService", Environment.MachineName)
    .WithTransport(new RedisTransportConfiguration().WithConnectionString("localhost:6379"))
    .WithAutoDeleteOnIdle(TimeSpan.FromDays(1)) // Optional, defaults to 4 days, minimum 5 minutes
    .WithTypesFrom(typeProvider)
    .WithAutofacDefaults(container)
    .Build();

A running instance keeps refreshing its own heartbeat regardless of message traffic, so an idle topic doesn’t trigger cleanup on its own — this window only matters once an instance stops. If it’s a deliberate pause rather than a permanent shutdown, any messages published to its subscription are lost once the idle window elapses and the queue is reaped. Raise WithAutoDeleteOnIdle if you rely on instances going quiet for extended periods and resuming later; the default assumes an instance that stops is gone for good.

The same setting also governs AutoDeleteOnIdle on Azure Service Bus queues and subscriptions, where it’s enforced by the broker rather than a client-side heartbeat.