Redis Pub/Sub vs Redis Streams — A Practical Guide to Choosing the Right Messaging Model
Redis provides multiple ways to handle messaging between services — with Pub/Sub and Streams being the two key built-in options. Although they may look similar at first glance, they solve very different problems. Choosing the wrong one can lead to message loss, scalability issues, or unnecessary complexity.
This article expands on the original discussion and adds practical guidance, architectural reasoning, and real-world decision rules for production systems.
What Are Redis Pub/Sub and Redis Streams?
Redis Pub/Sub — Fire-and-Forget Messaging
Redis Pub/Sub implements a classic publish / subscribe pattern:
- Publishers send messages to channels
- Subscribers …
Redis Pub/Sub vs Redis Streams — A Practical Guide to Choosing the Right Messaging Model
Redis provides multiple ways to handle messaging between services — with Pub/Sub and Streams being the two key built-in options. Although they may look similar at first glance, they solve very different problems. Choosing the wrong one can lead to message loss, scalability issues, or unnecessary complexity.
This article expands on the original discussion and adds practical guidance, architectural reasoning, and real-world decision rules for production systems.
What Are Redis Pub/Sub and Redis Streams?
Redis Pub/Sub — Fire-and-Forget Messaging
Redis Pub/Sub implements a classic publish / subscribe pattern:
- Publishers send messages to channels
- Subscribers receive messages only if they are connected at publish time
There is no message storage, retry, or replay mechanism.
Key Characteristics
| Feature | Pub/Sub |
|---|---|
| Message persistence | ❌ No |
| Delivery guarantee | At-most-once |
| Offline consumption | ❌ No |
| Consumer groups | ❌ No |
| Ordering | Best effort |
| Complexity | Very low |
When Pub/Sub Makes Sense
- Live UI updates (dashboards, live cursors, presence)
- Chat systems where missed messages are acceptable
- Broadcasting system state to connected clients
Core Limitation
If a subscriber is disconnected, slow, or crashes, the message is lost forever.
Redis Streams — Durable Event Logs
Redis Streams introduce a persistent, append-only log designed for reliable event processing.
Messages are stored in Redis and consumed at the consumer’s own pace.
Core Concepts
- Stream – ordered log of messages
- Message ID – monotonic unique identifier
- Consumer Group – coordinated consumption across multiple consumers
- ACK – confirms successful processing
- PEL (Pending Entries List) – tracks unacknowledged messages
Key Characteristics
| Feature | Streams |
|---|---|
| Message persistence | ✔ Yes |
| Delivery guarantee | At-least-once |
| Offline consumption | ✔ Yes |
| Consumer groups | ✔ Yes |
| Replay | ✔ Yes |
| Complexity | Medium–High |
When Streams Make Sense
- Job queues and background workers
- Event-driven microservices
- Audit logs and event sourcing
- Systems requiring recovery and retries
Side-by-Side Comparison
| Aspect | Pub/Sub | Streams |
|---|---|---|
| Persistence | No | Yes |
| Replay | No | Yes |
| ACK support | No | Yes |
| Consumer groups | No | Yes |
| Failure recovery | No | Yes |
| Latency | Very low | Low–medium |
| Operational complexity | Minimal | Moderate |
How Pub/Sub Works Internally
- Subscriber connects and subscribes to a channel
- Publisher publishes a message
- Redis immediately pushes the message to all active subscribers
If the subscriber is not connected at that moment, the message is dropped.
There is no back-pressure handling and no message history.
How Redis Streams Work Internally
- Producer appends messages using
XADD - Redis stores messages with unique IDs
- Consumers read messages using
XREADorXREADGROUP - Consumers acknowledge processing with
XACK - Unacknowledged messages remain in the PEL for recovery
Streams behave similarly to Kafka or SQS, but fully embedded in Redis.
Delivery Guarantees Explained
Pub/Sub — At-Most-Once
- Messages are delivered zero or one time
- No retry, no confirmation
- Best suited for non-critical data
Streams — At-Least-Once
- Messages are persisted
- Processing can be retried
- Consumers must handle potential duplicates
Scaling Considerations
Pub/Sub
- Extremely fast
- Minimal memory overhead
- Fan-out cost increases with subscriber count
Streams
- Higher memory usage
- Consumer groups distribute load
- Supports horizontal scaling and fault tolerance
Decision Rules (Use This in Real Projects)
| Scenario | Recommended Choice |
|---|---|
| Live notifications only | Pub/Sub |
| Business-critical processing | Streams |
| UI events | Pub/Sub |
| Distributed workers | Streams |
| Need replay or recovery | Streams |
| Minimal latency, no history | Pub/Sub |
Real-World Example
Notifications
- Only online users matter → Pub/Sub
- Every user must receive the message → Streams
Order Processing Pipeline
- Inventory, billing, shipping coordination → Streams
Common Mistakes
- Using Pub/Sub as a job queue ❌
- Expecting durability from Pub/Sub ❌
- Ignoring duplicate processing in Streams ❌
- Never trimming old stream entries ❌
Summary
Redis offers two messaging paradigms:
- Pub/Sub — simple, fast, ephemeral
- Streams — durable, reliable, replayable
Choose based on delivery guarantees, failure tolerance, and system complexity, not convenience.
Rule of thumb:
- Message loss acceptable → Pub/Sub
- Message loss unacceptable → Streams
Further Reading
- Redis Pub/Sub Documentation
- Redis Streams Documentation
- System-design comparisons of Redis messaging patterns