Architecting Real-Time Signaling with Redis Pub/Sub

The Problem: Transient Signaling vs. Durable Queuing

Engineers often reach for a message broker when they need to decouple microservices. However, using a heavy-duty queue (like RabbitMQ or Kafka) for simple, real-time notifications—such as updating a UI via WebSockets or triggering a cache invalidation—introduces unnecessary disk I/O and management overhead. The core challenge is selecting a mechanism that prioritizes low latency over durability.

The Takeaway: Redis Pub/Sub is the ideal choice for transient signaling where the loss of a message during a subscriber's downtime is acceptable, but delivery latency must be minimized.

The Smallest Suitable Design

A minimal Redis Pub/Sub architecture consists of a single Redis instance (or a cluster) acting as the message bus. Unlike Redis Lists or Streams, Pub/Sub does not store data in a key-value pair; it is a push-based mechanism.

• Publisher: A service that sends a message to a named channel. It does not know who is listening.
• Channel: A logical routing key (e.g., user.notifications.123).
• Subscriber: A service that maintains an open connection to Redis and listens for messages on one or more channels.

In a Redis Cluster environment, Pub/Sub messages are broadcast to all nodes. This ensures that regardless of which node a subscriber is connected to, they receive the message, but it increases the internal network traffic across the cluster.

Trust and Data Boundaries

Because any client with access to the Redis instance could potentially listen to all traffic or spoof messages, you must implement Access Control Lists (ACLs) to define boundaries.

Restrict permissions based on the service role. For example, a Notification Service should have permission to publish, while a Frontend Gateway should only have permission to subscribe.

# Run these commands via redis-cli as an administrator
# Create a subscriber user who can only subscribe to the 'alerts' channel
ACL SETUSER subscriber_user on >password123 ~alerts +subscribe

# Create a publisher user who can only publish to the 'alerts' channel
ACL SETUSER publisher_user on >password456 ~alerts +publish

Operational Checks and Verification

To verify the implementation, use two separate redis-cli sessions. This confirms the asynchronous nature of the delivery.

1. Session A (Subscriber): Run SUBSCRIBE alerts. The client will enter a listening state and block further input.
2. Session B (Publisher): Run PUBLISH alerts "System Maintenance at 12:00".
3. Check: Session A should immediately display the message.

To monitor the health of your messaging system, track the pubsub_numsub command. This returns the number of subscribers for a specific channel, allowing you to detect if your subscriber services have crashed or disconnected.

Failure Modes and Limitations

Redis Pub/Sub is "fire-and-forget." This introduces specific failure modes that must be handled at the application level:

• Disconnected Subscribers: If a subscriber loses its connection for 10 milliseconds, any message published during that window is lost forever. There is no buffer or "replay" mechanism.
• The "Thundering Herd" Effect: Because every subscriber to a channel receives every message, you cannot use Pub/Sub for load-balancing work. If you have 10 instances of a service subscribed to orders, all 10 will process the same order.
• CPU Spikes: A massive number of channels or an explosion of subscribers can lead to high CPU usage on the Redis node due to the overhead of broadcasting messages to every connected socket.

When to Change the Design

You should migrate from Redis Pub/Sub to Redis Streams or a dedicated broker (like NATS or Kafka) if any of the following requirements emerge:

Requirement	Pub/Sub Limitation	Recommended Alternative
Guaranteed Delivery	Messages are lost if subscriber is offline.	Redis Streams (Consumer Groups)
Work Distribution	Every subscriber gets every message.	Redis Lists (RPOP/LPUSH)
Message History	No persistence; cannot see past messages.	Redis Streams