Redis Pub/Sub vs Redis Streams

Source: Dev.to

What Are Redis Pub/Sub and Redis Streams?

Redis Pub/Sub — Fire‑and‑Forget Messaging

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

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

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

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

# Producer appends a message
XADD mystream * field1 value1 field2 value2

# Consumer reads messages (group mode)
XREADGROUP GROUP mygroup consumer1 COUNT 10 STREAMS mystream >

# Consumer acknowledges processing
XACK mystream mygroup 1526985054069-0

• Redis stores messages with unique IDs.
• Consumers read messages using XREAD or XREADGROUP.
• Unacknowledged messages remain in the PEL for recovery.

Streams behave similarly to Kafka or SQS, but are 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)

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