Why pub/sub enables real-time messaging in Redis - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

How does pub/sub achieve real-time message delivery?

In Redis pub/sub, what is the main reason messages are delivered in real-time to subscribers?

A Subscribers must poll Redis repeatedly to check for new messages, which creates real-time delivery.

B Subscribers receive messages instantly because Redis pushes messages directly to them as soon as they are published.

C Messages are stored in a queue and delivered only when subscribers request them explicitly.

D Redis batches messages and sends them to subscribers at fixed time intervals.

💡 Hint

Think about how messages reach subscribers without delay.

Redis pub/sub pushes messages immediately to all subscribers of a channel, enabling real-time communication without polling or delays.

❓ query_result

intermediate

What output shows a subscriber receiving messages in real-time?

Given a Redis subscriber listening on channel 'news', what output will it show when messages are published?

Redis

SUBSCRIBE news

# Then publisher runs:
PUBLISH news "Hello"
PUBLISH news "World"

A

Subscribed to news channel
Hello
World

B

Hello
World

C

news: Hello
news: World

D

message
news
Hello
message
news
World

💡 Hint

Look at the exact Redis subscriber output format.

Redis subscriber outputs 'message', channel name, then the message for each published message.

📝 Syntax

advanced

Which Redis command syntax correctly subscribes to multiple channels?

Select the correct Redis command to subscribe to channels 'sports' and 'weather' simultaneously.

A SUBSCRIBE sports weather

B SUBSCRIBE sports, weather

C SUBSCRIBE 'sports' 'weather'

D SUBSCRIBE sports; SUBSCRIBE weather

💡 Hint

Redis commands separate multiple channels by spaces, not commas or semicolons.

The correct syntax is SUBSCRIBE followed by channel names separated by spaces without commas or quotes.

❓ optimization

advanced

How to reduce message loss in Redis pub/sub during high load?

Redis pub/sub does not store messages if no subscriber is connected. Which approach helps reduce message loss in real-time messaging?

A Subscribe to channels with pattern matching to catch all messages.

B Increase Redis server memory to buffer more pub/sub messages.

C Use Redis Streams instead of pub/sub to store messages until consumed.

D Publish messages less frequently to avoid overload.

💡 Hint

Think about message persistence and delivery guarantees.

Redis Streams store messages so consumers can read them later, preventing message loss unlike pub/sub which only delivers to active subscribers.

🔧 Debug

expert

Why does this Redis pub/sub subscriber miss some messages?

A subscriber runs SUBSCRIBE on channel 'alerts'. The publisher sends messages rapidly. Sometimes the subscriber misses messages. What is the most likely cause?

Redis

Subscriber:
SUBSCRIBE alerts

Publisher:
for i in range(1000):
  PUBLISH alerts f"Alert {i}"

A Subscriber cannot process messages fast enough, causing message loss because Redis pub/sub does not queue messages.

B Subscriber did not authenticate properly, so messages are blocked.

C Publisher is using wrong channel name, so messages go elsewhere.

D Redis server is down, so messages are lost.

💡 Hint

Consider how Redis pub/sub handles message delivery under load.

Redis pub/sub delivers messages only to connected subscribers instantly. If subscriber is slow, messages sent while it is busy are lost.

Practice

1. What is the main reason Redis Pub/Sub enables real-time messaging?

easy

A. Subscribers must request messages manually.

B. Messages are stored permanently for later retrieval.

C. Messages are sent instantly to all subscribers as soon as they are published.

D. It uses batch processing to send messages every hour.

Solution

1. Step 1: Understand Pub/Sub message delivery

   Redis Pub/Sub sends messages immediately to all clients subscribed to a channel.

2. Step 2: Compare with other messaging methods

   Unlike storing messages or batch sending, Pub/Sub delivers instantly without delay.

3. Final Answer:

   Messages are sent instantly to all subscribers as soon as they are published. -> Option C

4. Quick Check:

   Instant delivery = Real-time messaging [OK]

Hint: Instant delivery means real-time messaging [OK]

Common Mistakes:

• Thinking messages are stored permanently
• Believing subscribers pull messages manually
• Confusing batch sending with real-time

2. Which Redis command is used by a client to subscribe to a channel for real-time messages?

easy

A. SET

B. PUBLISH

C. GET

D. SUBSCRIBE

Solution

1. Step 1: Identify subscription command

   The SUBSCRIBE command tells Redis the client wants to listen to messages on a channel.

2. Step 2: Differentiate from other commands

   PUBLISH sends messages; GET and SET are for key-value operations, not subscriptions.

3. Final Answer:

   SUBSCRIBE -> Option D

4. Quick Check:

   SUBSCRIBE = listen to messages [OK]

Hint: SUBSCRIBE means start listening to a channel [OK]

Common Mistakes:

• Using PUBLISH to subscribe
• Confusing GET/SET with Pub/Sub commands
• Thinking SUBSCRIBE stores messages

3. Consider this Redis Pub/Sub interaction:

Client A: SUBSCRIBE news
Client B: PUBLISH news "Hello World!"

What will Client A receive?

medium

A. "Hello World!" message immediately

B. No message because Client A subscribed after publishing

C. An error message

D. The message after a delay of 10 seconds

Solution

1. Step 1: Analyze subscription timing

   Client A subscribes before Client B publishes, so Client A is listening when message is sent.

2. Step 2: Understand Pub/Sub delivery

   Messages are delivered instantly to all current subscribers on the channel.

3. Final Answer:

   "Hello World!" message immediately -> Option A

4. Quick Check:

   Subscribed before publish = immediate message [OK]

Hint: Subscribers get messages instantly if subscribed before publish [OK]

Common Mistakes:

• Thinking message is delayed
• Assuming message is lost if published after subscribe
• Expecting error on publish

4. You wrote this Redis Pub/Sub code:

SUBSCRIBE sports
PUBLISH sports "Game starts now!"

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

medium

A. Messages are stored and delivered later, so subscriber must check history.

B. The subscriber must run SUBSCRIBE and listen continuously; mixing commands causes issues.

C. Redis does not support Pub/Sub.

D. PUBLISH command is misspelled.

Solution

1. Step 1: Understand Pub/Sub client behavior

   SUBSCRIBE blocks the client to listen continuously; mixing it with PUBLISH in same client causes no message received.

2. Step 2: Identify correct usage

   Separate clients should SUBSCRIBE and PUBLISH; subscriber must stay connected to receive messages.

3. Final Answer:

   The subscriber must run SUBSCRIBE and listen continuously; mixing commands causes issues. -> Option B

4. Quick Check:

   Separate clients for SUBSCRIBE and PUBLISH [OK]

Hint: SUBSCRIBE blocks; use separate clients for publish and subscribe [OK]

Common Mistakes:

• Running SUBSCRIBE and PUBLISH in same client
• Expecting Redis to store messages
• Assuming misspelled commands cause silent failure

5. You want to build a live notification system using Redis Pub/Sub. Which approach best ensures users get notifications instantly and reliably?

hard

A. Use Pub/Sub for instant delivery and also store notifications in a list for missed messages.

B. Only use Pub/Sub without storing messages; rely on clients always connected.

C. Store all messages in Redis keys and have clients poll every minute.

D. Send notifications via email instead of Pub/Sub.

Solution

1. Step 1: Understand Pub/Sub strengths and limits

   Pub/Sub delivers instantly but does not store messages for offline clients.

2. Step 2: Combine real-time and reliability

   Storing notifications in a list allows clients to fetch missed messages if disconnected.

3. Step 3: Evaluate other options

   Polling causes delay; email is not real-time; relying only on Pub/Sub risks lost messages.

4. Final Answer:

   Use Pub/Sub for instant delivery and also store notifications in a list for missed messages. -> Option A

5. Quick Check:

   Combine Pub/Sub + storage = instant + reliable [OK]

Hint: Combine Pub/Sub with storage for reliability [OK]

Common Mistakes:

• Relying only on Pub/Sub without storage
• Using polling causing delays
• Confusing email with real-time messaging