Implementing Real-Time Signaling with Redis Pub/Sub

The Core Trade-off: Speed vs. Persistence

Redis Pub/Sub (Publish/Subscribe) is designed for high-throughput, low-latency signaling where the immediate delivery of a message is more important than ensuring every single message is received. The critical takeaway for engineers is that Redis Pub/Sub is a fire-and-forget mechanism. It does not store messages; if a client is disconnected or not subscribed at the exact moment a message is published, that data is permanently lost.

This makes it ideal for real-time notifications, chat presence indicators, or triggering cache invalidation across multiple application servers, but unsuitable for task queues or financial transaction logs where delivery guarantees are mandatory.

How the Mechanism Works

In a Pub/Sub architecture, publishers and subscribers are decoupled. A publisher sends a message to a named channel without knowing who (if anyone) is listening. Subscribers register their interest in one or more channels, and Redis pushes the messages to them as they arrive.

The Subscriber State

When a client issues a SUBSCRIBE command, the connection enters a "subscriber state." In this state, the connection is dedicated to listening for messages. The client cannot execute standard Redis commands like SET, GET, or HGETALL on that specific connection. To perform data operations while subscribed, you must maintain a separate connection pool.

Pattern-Based Subscriptions

Beyond specific channels, Redis supports PSUBSCRIBE, which uses glob-style patterns. This allows a client to listen to a category of channels (e.g., user.events.*) without knowing every individual channel name in advance.

Worked Example: Cross-Server Cache Invalidation

Imagine a distributed system with three application servers. When Server A updates a user profile in the database, Servers B and C must clear their local in-memory caches for that user.

Step 1: Set up subscribers
Run the following command on each application server (via redis-cli or a client library) using a dedicated connection:

# Run on Server A, B, and C
SUBSCRIBE cache_invalidation

Step 2: Publish the invalidation event
When Server A updates the database, it publishes the ID of the affected user to the channel:

# Run on Server A
PUBLISH cache_invalidation "user_12345"

Expected Result:
All three servers (including the publisher) receive the message "user_12345" and trigger their local cache purge logic. If a fourth server joins the cluster after this command is run, it will not receive the notification and will continue serving stale data until the next update.

Performance and Complexity

The time complexity for message delivery is O(N+M), where N is the number of subscribers and M is the number of subscribed channels. Because Redis does not track acknowledgments or maintain message offsets, the overhead is minimal, allowing for extremely high message volumes.

Critical Limitations and Common Mistakes

The "Missing Message" Trap

The most common mistake is treating Pub/Sub like a message queue (such as RabbitMQ or Redis Streams). In a queue, messages wait for a consumer. In Pub/Sub, if the subscriber's network connection flickers for one second, any messages sent during that window are gone forever. If your use case requires "at-least-once" delivery, use Redis Streams instead.

Network Saturation

Because Redis pushes data to all subscribers simultaneously, a single large message published to a channel with 1,000 subscribers can cause a sudden spike in outbound network bandwidth. Avoid sending large payloads (like full JSON blobs) through Pub/Sub; instead, publish a small identifier or a pointer to a key in Redis that the subscribers can then fetch using a standard GET command.

Connection Blocking

Attempting to use a subscribed connection for general data queries will result in an error. Ensure your application architecture separates the PubSubConnection from the DataConnection.

Verification Checklist

• Connection Test: Open two terminal sessions with redis-cli. Run SUBSCRIBE test_chan in one and PUBLISH test_chan "hello" in the other. Confirm the message appears in the subscriber terminal.
• State Test: In the subscriber terminal, attempt to run SET key value. The command should fail or be rejected because the connection is in subscriber mode.
• Persistence Test: Publish a message to a channel with no subscribers. Subscribe to that channel immediately after. Verify that the previous message was not received.