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

1. Subscriber connects and subscribes to a channel
2. Publisher publishes a message
3. 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

1. Producer appends messages using XADD
2. Redis stores messages with unique IDs
3. Consumers read messages using XREAD or XREADGROUP
4. Consumers acknowledge processing with XACK
5. 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