Pub Sub vs Streams in Redis: Key Differences and When to Use Each

In Redis, Pub/Sub is a simple messaging system for real-time message delivery without persistence, while Streams provide a durable, log-based message queue with message history and consumer groups. Use Pub/Sub for fast, ephemeral broadcasts and Streams when you need message persistence and reliable processing.

Quick Comparison

This table summarizes the main differences between Redis Pub/Sub and Streams.

Feature	Pub/Sub	Streams
Message Delivery	Real-time, no persistence	Durable, stored in a log
Message Persistence	No	Yes, messages are saved
Consumer Model	Subscribers receive messages live	Supports consumer groups with message tracking
Message Acknowledgment	No ack, fire-and-forget	Supports explicit acknowledgments
Use Case	Live chat, notifications	Event sourcing, task queues
Scalability	Limited by subscriber connection	High, with consumer groups and history

Key Differences

Pub/Sub in Redis is a simple publish-subscribe messaging pattern where messages are sent to all currently connected subscribers instantly. It does not store messages, so if a subscriber is offline, it misses those messages. This makes it ideal for real-time notifications where message loss is acceptable.

On the other hand, Streams are a more advanced data structure that stores messages in an append-only log. This allows consumers to read messages at their own pace, even if they were offline when the message was published. Streams support consumer groups, enabling multiple consumers to share the workload and track which messages have been processed.

Another key difference is message acknowledgment: Streams allow consumers to acknowledge messages after processing, ensuring reliable delivery and the ability to retry failed messages. Pub/Sub lacks this feature, making it less reliable for critical message processing.

Code Comparison

Here is how you publish and subscribe to messages using Redis Pub/Sub.

redis

127.0.0.1:6379> SUBSCRIBE news
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "news"
3) (integer) 1

# In another terminal
127.0.0.1:6379> PUBLISH news "Hello subscribers!"
(integer) 1

Output

1) "message"
2) "news"
3) "Hello subscribers!"

Streams Equivalent

Here is how you add and read messages using Redis Streams with a consumer group.

redis

127.0.0.1:6379> XGROUP CREATE mystream mygroup $ MKSTREAM
OK

127.0.0.1:6379> XADD mystream * message "Hello stream!"
"1609459200000-0"

127.0.0.1:6379> XREADGROUP GROUP mygroup consumer1 COUNT 1 STREAMS mystream >
1) 1) "mystream"
   2) 1) 1) "1609459200000-0"
         2) 1) "message"
            2) "Hello stream!"

Output

1) 1) "mystream"
   2) 1) 1) "1609459200000-0"
         2) 1) "message"
            2) "Hello stream!"

When to Use Which

Choose Pub/Sub when you need simple, fast, real-time message broadcasting without the need to store messages or guarantee delivery. It is perfect for live notifications, chat messages, or ephemeral events where missing a message is not critical.

Choose Streams when you require message durability, the ability to replay messages, or reliable processing with acknowledgments. Streams are ideal for event sourcing, task queues, and systems where message loss cannot be tolerated and consumers may process messages at different speeds.

Key Takeaways

Use Redis Pub/Sub for fast, real-time messaging without persistence or delivery guarantees.

Use Redis Streams for durable message storage, consumer groups, and reliable processing.

Streams support message acknowledgment and replay, unlike Pub/Sub.

Pub/Sub is simpler but less reliable; Streams are more complex but robust.

Choose based on your need for message durability and consumer coordination.