Pub/sub vs streams comparison in Redis - Visual Side-by-Side Comparison

Concept Flow - Pub/sub vs streams comparison

Publish message

↓

Subscribers get message

↓

No message history

↓

Messages lost if offline

↓

Simple, real-time only

↓

Choose based on use case

Shows the flow of messages in Pub/Sub and Streams, highlighting real-time delivery vs durable storage.

Execution Sample

Redis

PUBLISH news "Hello"
SUBSCRIBE news
XADD mystream * message "Hello"
XREAD COUNT 1 STREAMS mystream 0

Publishes a message to a channel and adds a message to a stream, then reads from the stream.

Execution Table

Step	Command	Action	Result
1	PUBLISH news "Hello"	Send message to 'news' channel	Subscribers to 'news' receive 'Hello' immediately
2	SUBSCRIBE news	Subscribe client to 'news' channel	Client will receive future messages published to 'news'
3	XADD mystream * message "Hello"	Add message to 'mystream' stream	Message stored with ID, durable in stream
4	XREAD COUNT 1 STREAMS mystream 0	Read one message from 'mystream' starting at ID 0	Returns the stored message 'Hello'
5	PUBLISH news "World"	Send another message to 'news' channel	Subscribers receive 'World' immediately
6	XREAD COUNT 1 STREAMS mystream 0	Read next message from 'mystream'	No new message, returns empty
7	Client offline during PUBLISH	Message sent to 'news' while client offline	Client misses message, no recovery
8	Client offline during XADD	Message added to stream while client offline	Client can read message later from stream

💡 Execution stops after showing message delivery and storage differences between Pub/Sub and Streams.

Variable Tracker

Variable	Start	After Step 1	After Step 3	After Step 5	After Step 8
PubSub Channel 'news'	empty	message 'Hello' sent	message 'Hello' sent	message 'World' sent	message 'World' sent
Stream 'mystream'	empty	message 'Hello' stored	message 'Hello' stored	message 'Hello' stored	message 'Hello' stored

Key Moments - 3 Insights

Why does a subscriber miss messages if offline in Pub/Sub?

Because Pub/Sub delivers messages only to connected clients at publish time (see execution_table step 7). Offline clients do not get stored messages.

How does Streams ensure message durability?

Streams store messages with IDs in a log, so clients can read messages later even if they were offline (see execution_table steps 3, 4, and 8).

Can Pub/Sub messages be replayed after delivery?

No, Pub/Sub messages are transient and not stored, so they cannot be replayed (see execution_table step 7).

Visual Quiz - 3 Questions

Look at the execution_table, what happens at step 4 when reading from the stream?

A The stored message 'Hello' is returned

B No message is returned

C A new message is published to the channel

D The stream is deleted

💡 Hint

Check the 'Result' column in execution_table row for step 4

At which step does the Pub/Sub subscriber miss a message due to being offline?

A Step 2

B Step 7

C Step 3

D Step 8

💡 Hint

Look for the step describing client offline during PUBLISH in execution_table

If you want to replay messages after being offline, which Redis feature should you use?

A Pub/Sub

B Sorted Sets

C Streams

D Hashes

💡 Hint

Refer to key_moments about message durability and replay

Concept Snapshot

Pub/Sub delivers messages instantly to connected clients only.
No message history; offline clients miss messages.
Streams store messages with IDs for durability.
Clients can read and replay messages later.
Choose Pub/Sub for simple real-time needs.
Choose Streams for reliable, replayable messaging.

Full Transcript

This visual execution compares Redis Pub/Sub and Streams. Pub/Sub sends messages immediately to connected subscribers but does not store messages. If a subscriber is offline, it misses messages. Streams store messages with unique IDs, allowing clients to read messages later, even if they were offline. The execution table shows publishing and subscribing steps, message storage in streams, and how clients read messages. Key moments clarify why Pub/Sub messages are transient and Streams provide durability. The quiz tests understanding of message delivery, offline behavior, and replay capabilities. This helps beginners see the practical differences and choose the right Redis feature for their needs.

Practice

1. Which Redis feature is best suited for instant message delivery without storing messages?

easy

A. Hashes

B. Streams

C. Pub/Sub

D. Sorted Sets

Solution

1. Step 1: Understand Pub/Sub purpose

   Pub/Sub delivers messages instantly to subscribers without saving them.

2. Step 2: Compare with Streams

   Streams store messages for later processing, unlike Pub/Sub.

3. Final Answer:

   Pub/Sub -> Option C

4. Quick Check:

   Instant delivery without storage = Pub/Sub [OK]

Hint: Instant delivery without storage means Pub/Sub [OK]

Common Mistakes:

• Confusing Streams with Pub/Sub for instant delivery
• Thinking Streams do not store messages
• Choosing data structures unrelated to messaging

2. Which of the following is the correct Redis command to publish a message to a channel named news?

easy

A. PUBLISH news "Hello"

B. XADD news * message "Hello"

C. SUBSCRIBE news

D. GET news

Solution

1. Step 1: Identify publish command syntax

   The PUBLISH command sends a message to a channel immediately.

2. Step 2: Check other commands

   XADD adds to streams, SUBSCRIBE listens, GET retrieves keys, so only PUBLISH fits.

3. Final Answer:

   PUBLISH news "Hello" -> Option A

4. Quick Check:

   Publish message = PUBLISH command [OK]

Hint: Use PUBLISH to send messages to channels [OK]

Common Mistakes:

• Using XADD instead of PUBLISH for Pub/Sub
• Confusing SUBSCRIBE with PUBLISH
• Using GET which is for keys, not messages

3. Given the following Redis commands, what will be the output of XREAD COUNT 2 STREAMS mystream 0 after adding two entries with XADD mystream * field1 val1 and XADD mystream * field2 val2?

medium

A. An error because COUNT is invalid here

B. Two entries with their IDs and fields returned

C. No entries returned because 0 means no messages

D. Only the first entry returned ignoring COUNT

Solution

1. Step 1: Understand XADD and XREAD

   XADD adds entries to a stream with unique IDs. XREAD reads entries from streams.

2. Step 2: Analyze XREAD COUNT 2 STREAMS mystream 0

   This reads up to 2 entries from 'mystream' starting from ID 0 (the beginning).

3. Final Answer:

   Two entries with their IDs and fields returned -> Option B

4. Quick Check:

   XREAD with COUNT 2 returns up to 2 entries [OK]

Hint: XREAD with COUNT returns that many entries from stream start [OK]

Common Mistakes:

• Thinking COUNT is invalid in XREAD
• Assuming 0 means no messages returned
• Expecting only one entry despite COUNT 2

4. You wrote this Redis command to subscribe to a channel: SUBSCRIBE mychannel. But your client never receives messages published with PUBLISH mychannel "Hello". What is the likely problem?

medium

A. The client must use XREAD to receive Pub/Sub messages

B. PUBLISH command syntax is wrong

C. Streams must be used instead of Pub/Sub for messages

D. The client is not listening because it did not call SUBSCRIBE correctly

Solution

1. Step 1: Verify SUBSCRIBE usage

   SUBSCRIBE must be called on the client to listen to messages; if not, no messages arrive.

2. Step 2: Check other options

   PUBLISH syntax is correct; Streams and XREAD are unrelated to Pub/Sub listening.

3. Final Answer:

   The client is not listening because it did not call SUBSCRIBE correctly -> Option D

4. Quick Check:

   Client must SUBSCRIBE to receive messages [OK]

Hint: Client must SUBSCRIBE to receive published messages [OK]

Common Mistakes:

• Thinking PUBLISH syntax is wrong
• Confusing Streams with Pub/Sub for message delivery
• Using XREAD to get Pub/Sub messages

5. You want to build a task queue in Redis where tasks must be stored reliably and processed even if the worker restarts. Which Redis feature should you use and why?

hard

A. Use Streams because they store messages and support replaying tasks

B. Use Sorted Sets because they keep tasks ordered by score

C. Use Pub/Sub because it delivers messages instantly without storage

D. Use Hashes because they store key-value pairs efficiently

Solution

1. Step 1: Identify requirements for task queue

   Tasks must be stored reliably and processed even after worker restarts.

2. Step 2: Compare Redis features

   Pub/Sub does not store messages, so tasks can be lost. Streams store messages and allow replay.

3. Final Answer:

   Use Streams because they store messages and support replaying tasks -> Option A

4. Quick Check:

   Reliable storage and replay = Streams [OK]

Hint: Reliable task queues need Streams, not Pub/Sub [OK]

Common Mistakes:

• Choosing Pub/Sub for reliable storage
• Confusing Sorted Sets with message storage
• Using Hashes which are not for message queues