Limitations of Pub/Sub in Redis: What You Need to Know

Redis Pub/Sub does not store messages, so subscribers only receive messages while connected. It also lacks delivery guarantees and message durability, making it unsuitable for critical messaging needs.

Syntax

The basic Redis Pub/Sub commands include:

• PUBLISH channel message: Sends a message to all subscribers of the channel.
• SUBSCRIBE channel [channel ...]: Subscribes the client to one or more channels to receive messages.
• UNSUBSCRIBE [channel ...]: Unsubscribes the client from channels.

These commands enable simple message broadcasting but do not store messages.

redis

SUBSCRIBE news
PUBLISH news "Hello subscribers!"
UNSUBSCRIBE news

Example

This example shows a subscriber receiving messages only while connected. If the subscriber disconnects, it misses messages sent during that time.

bash

# Terminal 1 (Subscriber)
redis-cli
SUBSCRIBE news

# Terminal 2 (Publisher)
redis-cli
PUBLISH news "Breaking news: Redis Pub/Sub example!"

# If subscriber disconnects here and publisher sends more messages, they are lost to subscriber.

Output

1) "subscribe"
2) "news"
3) (integer) 1
1) "message"
2) "news"
3) "Breaking news: Redis Pub/Sub example!"

Common Pitfalls

1. No message persistence: Messages are not saved, so disconnected subscribers miss them.

2. No delivery guarantees: Messages may be lost if clients are slow or disconnected.

3. Scaling issues: Pub/Sub does not work across Redis clusters natively, limiting horizontal scaling.

4. No message filtering: Subscribers receive all messages on subscribed channels without advanced filtering.

redis

/* Wrong: Expecting message after disconnect */
SUBSCRIBE news
# Disconnect subscriber
PUBLISH news "Missed message"

/* Right: Use Redis Streams or external queue for persistence */
XADD mystream * message "Persistent message"

Quick Reference

Limitation	Description
No message persistence	Messages are not stored; missed if subscriber disconnected.
No delivery guarantees	Messages can be lost if client is slow or disconnected.
No message durability	No way to replay or recover messages.
Scaling challenges	Does not support native clustering for Pub/Sub.
No advanced filtering	Subscribers get all messages on subscribed channels.

Key Takeaways

Redis Pub/Sub does not save messages; subscribers must be connected to receive them.

There are no guarantees that messages will be delivered to all subscribers.

Pub/Sub does not scale well across Redis clusters without extra setup.

For reliable messaging, consider Redis Streams or external message brokers.

Pub/Sub is best for simple, real-time message broadcasting where loss is acceptable.