Using Redis Pub Sub Node Js

What is Redis Pub/Sub

Redis Pub/Sub (Publish/Subscribe) is a lightweight messaging system that enables real-time communication between different parts of an application. Unlike traditional messaging systems that require message queues and persistent storage, Redis Pub/Sub is designed for speed--messages are delivered instantly to all subscribed clients without being written to disk.

The architecture consists of three key elements working together. Publishers are responsible for sending messages to specific channels using the PUBLISH command. Channels serve as message distribution points--any message sent to a channel is immediately broadcast to all subscribers of that channel. Subscribers listen to one or more channels and receive messages in real-time as they are published. This decoupled architecture means you can add new publishers or subscribers without modifying existing code, making the system highly extensible.

This pattern is particularly valuable for modern web applications that require instant updates, such as live dashboards, notification systems, and event-driven microservices architectures.

Setting Up Redis with Node.js

Install the official Redis client and establish a connection in your application. The client provides promise-based APIs with async/await support for cleaner asynchronous code.

Installation

npm install redis

Connection Setup

import { createClient } from "redis"

const client = createClient({
 url: "redis://127.0.0.1:6379",
})

client.on("error", (err) => console.log("Redis Error", err))

await client.connect()
console.log("Connected to Redis!")

Error handling is essential for production applications where Redis connectivity directly impacts functionality. The connection setup includes proper error handlers to catch and log any connection issues.

When building applications with Redis Pub/Sub, consider separating your publisher and subscriber logic into distinct modules or even separate services. This separation allows you to scale publishers and subscribers independently based on load requirements. For serverless Node.js applications, Redis Pub/Sub can provide real-time event handling across function invocations.

Building a Publisher

Publishers send messages to channels using the publish() method. Messages can be simple strings or serialized JSON objects containing structured data. The publish method is non-blocking--Redis delivers the message asynchronously to all subscribers without waiting for any response from the publisher.

Basic Publisher

// publisher.js
setInterval(async () => {
 const message = `Current Time: ${new Date().toISOString()}`
 await client.publish("time_channel", message)
 console.log("📤 Published:", message)
}, 2000)

Publishing Structured Data

await publisher.publish(
 "order:created",
 JSON.stringify({
 id: "order-12345",
 customerId: "cust-789",
 total: 149.99,
 timestamp: new Date().toISOString()
 })
)

This example demonstrates a publisher that broadcasts events--in real-world applications, your publishers might be triggered by database changes, API requests, or events from other services. Use consistent naming conventions like entity:action to organize message channels effectively.

The key insight is that publishers operate independently of subscribers--they don't know or care how many subscribers exist or what they do with the messages. This loose coupling is what makes Redis Pub/Sub so powerful for distributed systems and microservices architectures.

Building a Subscriber

Subscribers register callbacks that execute when messages are published to their channels. The subscription is persistent--once subscribed, a client continues receiving messages until it explicitly unsubscribes or the connection closes.

Basic Subscriber

// receiver.js
await client.subscribe("time_channel", (message) => {
 console.log("📥 Received:", message)
})

Pattern-Based Subscriptions

Subscribe to multiple channels using wildcards for flexible message filtering:

await client.pSubscribe("order:*", (message, channel) => {
 const eventType = channel.split(":")[1]
 const order = JSON.parse(message)

 switch (eventType) {
 case "created":
 console.log(`🎉 New order: ${order.id}`)
 break
 case "shipped":
 console.log(`🚚 Shipped: ${order.id}`)
 break
 }
})

Pattern subscriptions use Redis's PSUBSCRIBE command, which accepts glob-style patterns like order:* to match channels such as order:created, order:updated, and `order:shipped. This is particularly powerful in microservices architectures where different services need to react to different subsets of events from a common source.

Redis Streams for Reliable Messaging

While Redis's basic Pub/Sub is incredibly fast, it has a significant limitation: it's fire-and-forget. If a subscriber is offline when a message is published, that message is lost forever. This is where Redis Streams come in--providing a persistent, log-like data structure that stores messages until they're explicitly consumed and acknowledged.

Streams allow multiple consumers to read from the same stream, and unacknowledged messages can be reassigned to other consumers--a crucial feature for building reliable production systems.

Creating a Consumer Group

await client.xGroupCreate("orders:stream", "email-service", "0", {
 MKSTREAM: true
})

Reliable Consumer with Acknowledgments

while (true) {
 const streams = await client.xReadGroup(
 "email-service",
 "consumer-1",
 { key: "orders:stream", id: ">" },
 { COUNT: 10, BLOCK: 5000 }
 )

 if (streams) {
 for (const { messages } of streams) {
 for (const { id, message } of messages) {
 console.log(`✉️ Processing: ${message.orderId}`)
 
 // Process message
 await sendOrderEmail(message)
 
 // Acknowledge processing
 await client.xAck("orders:stream", "email-service", id)
 }
 }
 }
}

Consumer groups solve the reliability problem by ensuring each message is processed by exactly one consumer. When a consumer reads a message, it must explicitly acknowledge it. If the consumer fails before acknowledging, the message becomes available for another consumer to pick up. The > ID requests only new messages, and explicit acknowledgments ensure reliable processing even if consumers fail.

Best Practices for Production

Error Handling and Reconnection

Production Redis Pub/Sub implementations must handle various failure scenarios gracefully. Redis connections can drop due to network issues, server restarts, or memory pressure. Implement automatic reconnection with exponential backoff to avoid overwhelming a struggling Redis server.

let reconnectDelay = 1000
client.on("reconnecting", () => {
 setTimeout(async () => {
 await client.connect()
 reconnectDelay = 1000
 await resubscribeToChannels()
 }, reconnectDelay)
 reconnectDelay = Math.min(reconnectDelay * 2, 30000)
})

Message Design Patterns

Design your messages with versioning and backward compatibility in mind. Include a message type or event name field that consumers can use to route messages to appropriate handlers:

const message = {
 schemaVersion: "1.2",
 eventType: "order.created",
 timestamp: new Date().toISOString(),
 data: { orderId: "12345", /* ... */ }
}

Scaling Considerations

As your application grows, you may need to scale Pub/Sub beyond a single Redis instance. Redis Cluster supports Pub/Sub with some limitations--channel operations work across the cluster, but messages are only delivered to clients connected to the node that owns the channel. When scaling subscribers, remember that each subscriber maintains its own connection to Redis. The Redis server can handle thousands of concurrent connections, but monitor memory usage and connection limits as your subscriber count grows.

For scalable backend architectures, consider implementing circuit breaker patterns to prevent cascading failures when Redis is unavailable. This approach works well with AI automation workflows that require reliable event processing and real-time data streaming.