PUBLISH-&-SUBSCRIBE
Publish messages to channels and subscribe to receive them in real-time. Fire-and-forget messaging for notifications, chat, and event-driven architectures.
You'll Learn
- PUBLISH and SUBSCRIBE basics
- Pattern subscriptions with PSUBSCRIBE
- Channel naming conventions
- When to use Pub/Sub vs Streams
See Your Data, Not Terminal Text
Redimo visualizes every Redis data type beautifully. Edit inline, undo mistakes, stay safe in production.
1. What Is Pub/Sub?
Pub/Sub (Publish/Subscribe) is a messaging pattern where publishers send messages to channels, and subscribers listening to those channels receive them instantly. It's fire-and-forget - messages are not persisted.
Unlike other Redis data structures, Pub/Sub doesn't store anything. If no subscribers are listening when a message is published, the message is simply lost. This makes it simple but requires careful architecture.
Syntax
SUBSCRIBE channel [channel ...] # Subscribe to channels (blocks!)
PSUBSCRIBE pattern [pattern ...] # Subscribe with glob patterns
PUBLISH channel message # Send message to channel
UNSUBSCRIBE [channel ...] # Unsubscribe from channels
PUNSUBSCRIBE [pattern ...] # Unsubscribe from patterns
PUBSUB CHANNELS [pattern] # List active channels
PUBSUB NUMSUB channel [channel ...] # Count subscribers per channelPub/Sub Properties
- • No message persistence
- • At-most-once delivery
- • No message acknowledgment
- • Broadcast to all subscribers
Good Use Cases
- • Real-time notifications
- • Cache invalidation
- • Live dashboards
- • Chat messages (ephemeral)
2. The CLI Way (Hard Mode)
Pub/Sub requires two terminal windows - one for subscribing (which blocks forever) and one for publishing:
Terminal 1 - Subscriber (Blocks)
127.0.0.1:6379> SUBSCRIBE notifications:user:1001
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "notifications:user:1001"
3) (integer) 1
# Waiting for messages... (connection is blocked)
# When a message arrives:
1) "message"
2) "notifications:user:1001"
3) "{\"type\":\"alert\",\"message\":\"New login from Tokyo\"}"
# More messages keep arriving...
1) "message"
2) "notifications:user:1001"
3) "{\"type\":\"friend_request\",\"from\":\"user:2001\"}"Terminal 2 - Publisher
127.0.0.1:6379> PUBLISH notifications:user:1001 "{\"type\":\"alert\",\"message\":\"New login\"}"
(integer) 1 # Number of subscribers who received it
127.0.0.1:6379> PUBLISH notifications:user:1001 "{\"type\":\"friend_request\"}"
(integer) 1
127.0.0.1:6379> PUBLISH notifications:user:9999 "no one listening"
(integer) 0 # No subscribers = message lost!The Problem
3. Understanding Pub/Sub Flow
Unlike other Redis data types, Pub/Sub doesn't store data. It's a real-time broadcast system:
Message Flow
All subscribers receive the same message simultaneously
Pub/Sub Limitations
- • No message persistence
- • No delivery guarantee
- • No replay/history
- • Subscriber must be connected
- • SUBSCRIBE blocks connection
When It Works Well
- • Real-time notifications
- • Cache invalidation signals
- • Live dashboard updates
- • Ephemeral chat
- • Event broadcasting
4. Pattern Subscriptions
PSUBSCRIBE uses glob patterns to subscribe to multiple channels at once:
Pattern Subscription Examples
# Subscribe to all notifications
PSUBSCRIBE notifications:*
# Subscribe to all user events
PSUBSCRIBE events:user:*
# Subscribe to all error channels
PSUBSCRIBE *.error
# When message arrives, you see the channel AND pattern:
1) "pmessage"
2) "notifications:*" # Pattern that matched
3) "notifications:user:1001" # Actual channel
4) "message content"Channel Management
# List active channels (with at least one subscriber)
PUBSUB CHANNELS
# List channels matching pattern
PUBSUB CHANNELS notifications:*
# Count subscribers per channel
PUBSUB NUMSUB notifications:user:1001 notifications:user:1002
# Returns: ["notifications:user:1001", 3, "notifications:user:1002", 1]
# Count pattern subscriptions
PUBSUB NUMPAT
# Returns total number of pattern subscriptions5. Pub/Sub vs Streams
Redis Streams (XADD, XREAD) are often a better choice for message queuing. Here's when to use each:
| Feature | Pub/Sub | Streams |
|---|---|---|
| Persistence | None | Yes, to disk |
| Message replay | No | Yes, read from any ID |
| Consumer groups | No | Yes |
| Acknowledgment | No | Yes (XACK) |
| Delivery | Broadcast to all | Per-consumer or group |
| Complexity | Simple | More complex |
Rule of Thumb
Use Streams when every message must be processed (job queues, event sourcing, audit logs).
6. Pro Tips
Channel Naming Convention
service:entity:id:eventExample:
notifications:user:1001:friend_requestPractical Patterns
# Cache invalidation
PUBLISH cache:invalidate "user:1001:profile"
# Subscribers clear their local cache for that key
# Live configuration updates
PUBLISH config:update "{\"feature_flags\":{\"dark_mode\":true}}"
# All services reload their config
# Distributed locking coordination
PUBLISH lock:released "resource:123"
# Waiting services can try to acquire
# Cluster communication
PUBLISH node:health "{\"node\":\"node-1\",\"status\":\"healthy\"}"SUBSCRIBE Blocks the Connection
Redimo and Pub/Sub
Ready to Message?
Pub/Sub is powerful but tricky to debug in CLI.
Download Redimo for easier Redis/Valkey management.