Redis Pub/Sub is a messaging paradigm where publishers send messages to channels, and subscribers receive messages from channels they’ve subscribed to. It’s a simple, yet powerful, mechanism for decoupling services and enabling real-time communication.
Let’s see it in action. Imagine we have a notifications service that needs to alert multiple downstream systems whenever a new order is placed.
# Start a Redis client
redis-cli
# In one terminal (the publisher)
# Publish a message to the 'orders' channel
> PUBLISH orders "new_order_12345"
# In another terminal (a subscriber)
# Subscribe to the 'orders' channel
> SUBSCRIBE orders
Reading messages...
1) "subscribe"
2) "orders"
3) (integer) 1
# Now, when the publisher sends a message:
1) "message"
2) "orders"
3) "new_order_12345"
This basic publish/subscribe model is the foundation for more complex patterns.
Fan-Out: Distributing Work to Multiple Workers
The "fan-out" pattern is used when a single message needs to be processed by multiple independent consumers, but each consumer should only process it once. Think of it like broadcasting an announcement to a group of people, where everyone hears it, but only one person needs to take action.
In Redis, this is achieved by having multiple subscribers listen to the same channel. When a publisher sends a message to that channel, all subscribers receive a copy of the message.
Example: A system that needs to log every incoming request to multiple logging services.
# Publisher (e.g., a web server)
> PUBLISH request_logs '{"ip": "192.168.1.100", "timestamp": "2023-10-27T10:00:00Z"}'
# Subscriber 1 (e.g., Elasticsearch logger)
> SUBSCRIBE request_logs
Reading messages...
1) "subscribe"
2) "request_logs"
3) (integer) 1
1) "message"
2) "request_logs"
3) '{"ip": "192.168.1.100", "timestamp": "2023-10-27T10:00:00Z"}'
# Subscriber 2 (e.g., Splunk logger)
> SUBSCRIBE request_logs
Reading messages...
1) "subscribe"
2) "request_logs"
3) (integer) 1
1) "message"
2) "request_logs"
3) '{"ip": "192.168.1.100", "timestamp": "2023-10-27T10:00:00Z"}'
Both subscribers receive the same log message. This is useful for redundancy or for different types of analysis on the same event.
Event Broadcasting: Global Notifications
Event broadcasting is very similar to fan-out, but the emphasis is on informing all interested parties about a significant event that has occurred. It’s less about distributing work and more about disseminating information.
Example: A real-time dashboard application where multiple clients need to know when a critical system metric changes.
# Service monitoring system
> PUBLISH critical_metric_change '{"metric": "CPU_Usage", "value": 95.5, "timestamp": "2023-10-27T10:05:00Z"}'
# Client 1 (dashboard widget)
> SUBSCRIBE critical_metric_change
Reading messages...
1) "subscribe"
2) "critical_metric_change"
3) (integer) 1
1) "message"
2) "critical_metric_change"
3) '{"metric": "CPU_Usage", "value": 95.5, "timestamp": "2023-10-27T10:05:00Z"}'
# Client 2 (alerting service)
> SUBSCRIBE critical_metric_change
Reading messages...
1) "subscribe"
2) "critical_metric_change"
3) (integer) 1
1) "message"
2) "critical_metric_change"
3) '{"metric": "CPU_Usage", "value": 95.5, "timestamp": "2023-10-27T10:05:00Z"}'
In both fan-out and event broadcasting, the key Redis command for publishers is PUBLISH channel message and for subscribers is SUBSCRIBE channel [channel ...].
The mental model here is that channels are like named radio frequencies. Anyone can tune into a frequency (SUBSCRIBE) and anyone can broadcast on it (PUBLISH). Redis itself acts as the central transmitter and receiver, ensuring messages get to all tuned-in listeners.
A crucial aspect often overlooked is the ephemeral nature of Redis Pub/Sub. Subscribers only receive messages published after they have subscribed. If a subscriber disconnects and then reconnects, it will miss any messages published during its downtime. For scenarios requiring guaranteed message delivery or historical message access, Redis Streams or other message queue technologies are more appropriate.
The next step in exploring Redis messaging patterns involves managing load distribution more intelligently with Redis Lists and blocking operations.