CHAPTER 11
Intermediate
Redis Pub/Sub Tutorial | Publish and Subscribe Systems
Updated: May 16, 2026
15 min read
# CHAPTER 11
Pub/Sub Messaging in Redis
1. Introduction
For the last 10 chapters, we have used Redis as a database—we store data, and later we retrieve it. But Redis possesses a completely different alter-ego. It is also an incredibly powerful Message Broker. Imagine you are building a Twitch-style live chat room or a live stock market ticker. If 10,000 users have their browsers open, how do you push a new message to all 10,000 screens simultaneously without crashing your server? You use the Publish/Subscribe (Pub/Sub) pattern. In this chapter, we will learn how to build real-time event broadcasting systems.2. Learning Objectives
By the end of this chapter, you will be able to:- Understand the Publisher/Subscriber architectural pattern.
-
Execute the
SUBSCRIBEcommand to listen for events.
-
Execute the
PUBLISHcommand to broadcast messages.
-
Utilize Pattern Subscriptions (
PSUBSCRIBE).
- Identify the limitations of "Fire and Forget" messaging.
3. The Concept of Pub/Sub
Pub/Sub works exactly like a radio station.- The Channel: The radio frequency (e.g., 99.5 FM).
- The Publisher: The DJ speaking into the microphone. They broadcast a message into the channel. They have no idea who is listening, or if anyone is listening at all.
- The Subscriber: A user tuning their car radio to 99.5 FM. They instantly hear whatever the DJ says.
*Crucial Architecture Note:* Messages in Pub/Sub are not stored in the database. If a Subscriber tunes in 5 seconds after the DJ speaks, they miss the message forever. It is "Fire and Forget".
4. Becoming a Subscriber (Listening)
To see this work, you must open two separate terminal windows side-by-side. In Terminal A, we will become a listener for a channel namednews_alerts.
bash
*(Terminal A will instantly freeze. It is now in "Listening Mode". It will sit there silently, waiting for data).*
5. Becoming a Publisher (Broadcasting)
In Terminal B, we will act as the backend server broadcasting a breaking news alert.
bash
*(Terminal B returns 1, meaning it successfully delivered the message to 1 listening client).*
Look back at Terminal A! The frozen terminal instantly printed the message:
1) "message"
2) "newsalerts"
3) "Earthquake detected!"
The real-time data transfer occurred in under a millisecond!
6. Pattern Subscribing (PSUBSCRIBE)
What if your application has hundreds of chat rooms (chat:room1, chat:room2, chat:roomadmin)? You want a master logging server to listen to *all* of them. You don't need to subscribe to 100 channels individually. You can use a wildcard *.
bash
*(This terminal will now instantly receive any message published to ANY channel that starts with "chat:").*
7. Real-World Use Case: Scaling WebSockets
Why do massive companies use Redis Pub/Sub? Imagine a Chat App. User Alice is connected to Server 1. User Bob is connected to Server 2. Alice types "Hello Bob." Server 1 receives it. But Server 1 doesn't know who Bob is, because Bob is on Server 2! The Redis Solution:-
1.
Both Server 1 and Server 2
SUBSCRIBEto the Redisglobalchatchannel.
-
2.
Server 1 takes Alice's message and
PUBLISHes it to Redis.
- 3. Redis instantly broadcasts it to Server 2.
- 4. Server 2 receives it and pushes it down the WebSocket to Bob's screen.
8. Mini Project: The Live Scoreboard
Scenario: A sports app updating live football scores.-
1.
Mobile phones load the app and
SUBSCRIBE match:championsleague.
- 2. A referee presses a button when a goal is scored.
-
3.
The backend server runs:
PUBLISH match:championsleague "GOAL! Team A scores!"
- 4. Redis instantly blasts that payload to 500,000 listening mobile phones simultaneously.
9. Common Mistakes
- Using Pub/Sub for Critical Data: A beginner uses Pub/Sub to send "Order Confirmation" emails to a background worker. The worker crashes for 10 seconds and disconnects. During those 10 seconds, 5 orders are placed. Because Pub/Sub does not store messages, those 5 emails are lost into the void forever. Never use Pub/Sub if message delivery must be guaranteed. (Use Redis Lists/Queues instead!).
10. Best Practices
-
JSON Payloads: The message you
PUBLISHis just a string. Best practice dictates broadcasting stringified JSON objects.
PUBLISH stockticker '{"symbol":"AAPL", "price":150.25, "time":"10:05"}'
This allows the listening servers to easily parse the data and update UI graphs.
11. Exercises
- 1. What command places a client into a frozen, listening state awaiting real-time events?
-
2.
If zero clients are currently subscribed to a channel, what happens to a message when you
PUBLISHit to that channel?
12. Redis Challenges
You are building an IoT (Internet of Things) dashboard. 10,000 temperature sensors are publishing their temperature every second to channels namedsensor:1, sensor:2, etc. You need to build a single "Global Alert" server that listens to all 10,000 sensors simultaneously to detect if any of them exceed 100 degrees. Which specific Redis command makes this architecturally possible without explicitly listing 10,000 channels?
*(Answer: The PSUBSCRIBE sensor:* command. By using Pattern Subscribing with a wildcard, the single server will automatically receive real-time streams from every sensor channel dynamically).*
13. MCQ Quiz with Answers
Question 1
In the Redis Pub/Sub architecture, what is the mathematical consequence of a publisher broadcasting a message into a channel while a specific subscriber is momentarily disconnected due to a network blip?
Question 2
An enterprise application utilizes Node.js servers and WebSockets to facilitate a live chat room. Why is integrating Redis Pub/Sub considered a mandatory architectural requirement when scaling the application from 1 Node.js server to 10 Node.js servers?
14. Interview Questions
- Q: Contrast the architectural use-case of a Redis List (acting as a Message Queue) versus Redis Pub/Sub. If you are building a billing system that generates PDF invoices, which pattern must you use and why?
- Q: Explain how Redis Pub/Sub facilitates the scaling of real-time WebSocket applications across horizontally distributed server clusters.
15. FAQs
Q: Can a client be both a Publisher and a Subscriber? A: In your backend code (like Node.js), yes. But mathematically, a single dedicated connection socket cannot do both at the same time. In your code, you will literally open *two* connections to Redis: one dedicated to listening, and one dedicated to publishing.16. Summary
You are now an event-driven architect. By transitioning from static data storage to the dynamic broadcasting power ofPUBLISH and SUBSCRIBE, you can build massive, real-time nervous systems capable of pushing live updates to millions of global devices in milliseconds.