Pub/sub limitations (no persistence) in Redis - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What happens to messages sent before a subscriber connects?

In Redis Pub/Sub, if a message is published to a channel before a client subscribes, what happens to that message?

A The subscriber receives the message once it connects.

B The message is lost and the subscriber does not receive it.

C The message is stored and delivered when the subscriber connects.

D The message is queued and delivered in order after subscription.

💡 Hint

Think about whether Redis Pub/Sub stores messages for future subscribers.

Redis Pub/Sub does not store messages. If a subscriber is not connected when a message is published, it misses that message.

🧠 Conceptual

intermediate

Why does Redis Pub/Sub not guarantee message delivery?

Which reason best explains why Redis Pub/Sub does not guarantee message delivery to subscribers?

A Because Redis stores messages only for a limited time.

B Because subscribers must acknowledge each message to receive the next.

C Because messages are sent only to currently connected subscribers without persistence.

D Because Redis queues messages for offline subscribers but drops them if full.

💡 Hint

Consider how Redis handles message storage and subscriber connection status.

Redis Pub/Sub sends messages only to subscribers connected at the time of publishing. It does not store or queue messages for later delivery.

📝 Syntax

advanced

Identify the incorrect Redis Pub/Sub command usage

Which of the following Redis commands is NOT valid for subscribing to a channel?

A SUBSCRIBER news

B PUBLISH news "Hello"

C SUBSCRIBE news sports

D SUBSCRIBE news

💡 Hint

Check the exact spelling of Redis Pub/Sub commands.

The correct command to subscribe is SUBSCRIBE. 'SUBSCRIBER' is not a valid Redis command.

🔧 Debug

advanced

Why does a subscriber miss messages after reconnecting?

A subscriber disconnects and then reconnects to a Redis Pub/Sub channel. It notices it missed messages sent during the disconnection. Why?

A Redis Pub/Sub queues messages but the queue was full.

B The subscriber was subscribed to the wrong channel after reconnecting.

C The subscriber did not send an ACK to receive missed messages.

D Redis Pub/Sub does not store messages for disconnected clients.

💡 Hint

Think about Redis Pub/Sub message persistence and client connection status.

Redis Pub/Sub does not store messages for clients that are disconnected. Messages sent during disconnection are lost to that client.

❓ optimization

expert

How to ensure message persistence with Redis Pub/Sub limitations?

Given Redis Pub/Sub does not persist messages, which approach best ensures message persistence and delivery to clients that may disconnect?

A Use Redis Streams instead of Pub/Sub for message persistence.

B Increase Redis memory to store more Pub/Sub messages.

C Use multiple Pub/Sub channels to duplicate messages.

D Subscribe clients with a delay to catch missed messages.

💡 Hint

Consider Redis features designed for message persistence and replay.

Redis Streams provide message persistence and allow clients to read messages even after disconnecting, unlike Pub/Sub.

Practice

1. What happens to messages sent via Redis Pub/sub if no clients are subscribed at that moment?

easy

A. Messages are lost and not stored anywhere.

B. Messages are saved and delivered later when clients subscribe.

C. Messages are queued until a client connects.

D. Messages are stored in a Redis list automatically.

Solution

1. Step 1: Understand Redis Pub/sub behavior

   Redis Pub/sub delivers messages only to clients currently subscribed.

2. Step 2: Analyze message persistence

   Since Pub/sub does not save messages, if no client listens, messages are lost.

3. Final Answer:

   Messages are lost and not stored anywhere. -> Option A

4. Quick Check:

   Pub/sub = no persistence [OK]

Hint: Pub/sub delivers live only, no message storage [OK]

Common Mistakes:

• Assuming messages queue up for later delivery
• Thinking messages are saved automatically
• Confusing Pub/sub with Redis streams

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

easy

A. SUBSCRIBE TO news

B. PUBLISH news

C. SUBSCRIBE news

D. LISTEN news

Solution

1. Step 1: Recall Redis Pub/sub subscribe syntax

   The correct command to subscribe is SUBSCRIBE <channel>.

2. Step 2: Match command to channel name

   Using SUBSCRIBE news subscribes to the channel named 'news'.

3. Final Answer:

   SUBSCRIBE news -> Option C

4. Quick Check:

   Subscribe syntax = SUBSCRIBE channel [OK]

Hint: Subscribe uses 'SUBSCRIBE channel' command [OK]

Common Mistakes:

• Using PUBLISH instead of SUBSCRIBE
• Adding extra words like TO
• Using LISTEN which is not a Redis command

3. Consider this Redis Pub/sub scenario:

Client A subscribes to channel 'chat'.
Client B publishes message 'Hello' to 'chat'.
Client C subscribes to 'chat' after the message is published.

Which clients receive the message 'Hello'?

medium

A. Only Client A

B. Clients A and C

C. Only Client C

D. Clients A, B, and C

Solution

1. Step 1: Identify subscribers at publish time

   Only Client A was subscribed when Client B published the message.

2. Step 2: Understand Pub/sub delivery

   Messages are sent only to clients subscribed at publish time; Client C subscribed later and misses the message.

3. Final Answer:

   Only Client A -> Option A

4. Quick Check:

   Subscribers at publish = receivers [OK]

Hint: Only current subscribers get messages [OK]

Common Mistakes:

• Assuming late subscribers get past messages
• Including publisher as receiver
• Thinking all clients get all messages

4. You wrote this Redis Pub/sub code snippet:

SUBSCRIBE news
PUBLISH news "Update 1"

But your subscriber never receives the message. What is the likely problem?

medium

A. The PUBLISH command syntax is incorrect.

B. The subscriber must be subscribed before the message is published.

C. Redis does not support Pub/sub messaging.

D. The channel name 'news' is reserved and cannot be used.

Solution

1. Step 1: Check Pub/sub message delivery timing

   Subscribers must be listening before messages are published to receive them.

2. Step 2: Analyze the code order

   If PUBLISH runs before SUBSCRIBE completes, subscriber misses the message.

3. Final Answer:

   The subscriber must be subscribed before the message is published. -> Option B

4. Quick Check:

   Subscribe first, then publish [OK]

Hint: Subscribe before publish to receive messages [OK]

Common Mistakes:

• Thinking PUBLISH syntax is wrong
• Believing Redis lacks Pub/sub support
• Assuming channel names are restricted

5. You want to ensure messages are not lost if no clients are currently subscribed. Which Redis feature should you use instead of Pub/sub?

hard

A. Use Redis transactions to save messages.

B. Use Pub/sub with multiple channels.

C. Increase Redis memory to save messages.

D. Redis Streams to store and consume messages later.

Solution

1. Step 1: Understand Pub/sub limitation

   Pub/sub does not store messages; they are lost if no subscriber is present.

2. Step 2: Identify Redis feature for persistence

   Redis Streams allow storing messages so clients can read them later.

3. Step 3: Evaluate other options

   Using multiple channels or transactions does not provide message persistence; increasing memory does not save messages automatically.

4. Final Answer:

   Redis Streams to store and consume messages later. -> Option D

5. Quick Check:

   Use Streams for persistence, not Pub/sub [OK]

Hint: Use Redis Streams for message persistence [OK]

Common Mistakes:

• Trying to fix Pub/sub by adding channels
• Thinking transactions save Pub/sub messages
• Assuming more memory stores messages