The Publish/Subscribe Model
Redis Pub/Sub lets clients subscribe to named channels with SUBSCRIBE channel-name, and any client can broadcast a message to every current subscriber of that channel with PUBLISH channel-name message. There is no persistence involved: Redis does not store messages anywhere, does not queue them for offline subscribers, and does not track delivery. A message published to a channel with zero active subscribers simply vanishes; PUBLISH returns the count of clients it was delivered to, which can legitimately be zero.
Cricket analogy: Pub/Sub is like a stadium's live PA announcer calling out a score update — anyone in the stadium at that exact moment hears it, but if you walk in five minutes later you've missed that announcement entirely, there's no replay booth storing it for you.
# Terminal 1: subscribe to a channel
SUBSCRIBE notifications:order-updates
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "notifications:order-updates"
3) (integer) 1
# Terminal 2: publish a message
PUBLISH notifications:order-updates '{"orderId":8821,"status":"shipped"}'
(integer) 1
# Back in Terminal 1, the message arrives:
1) "message"
2) "notifications:order-updates"
3) "{\"orderId\":8821,\"status\":\"shipped\"}"
# Pattern-based subscription across multiple channels
PSUBSCRIBE "notifications:*"Pattern Subscriptions and Channel Fan-Out
PSUBSCRIBE pattern lets a client subscribe using a glob-style pattern such as notifications:* to receive every message published to any channel matching that pattern, without needing to know every exact channel name in advance. This is useful for building generic dispatchers, for example a single logging or audit subscriber that listens to events:* across dozens of dynamically-named channels like events:user:42 and events:order:8821. Each matching client still receives its own independent copy of every message — PUBLISH fans a message out to all subscribers simultaneously; it is not a work queue where only one subscriber consumes each message.
Cricket analogy: PSUBSCRIBE is like a broadcaster subscribing to 'every match involving India' rather than naming each fixture individually — as new India fixtures get scheduled, the broadcaster automatically picks up coverage without re-subscribing to each one by name.
Fire-and-Forget: No Durability
Because Pub/Sub messages are never written to disk or replicated as data, a subscriber that's disconnected, restarting, or simply slow to process incoming messages will permanently miss anything published during that window; reconnecting only resumes receiving new messages from that point forward. Redis also does not implement consumer groups, acknowledgments, or message replay for Pub/Sub — it is fundamentally a broadcast mechanism for ephemeral, real-time notifications, not a durable message queue, and using it as one is a common and costly architectural mistake.
Cricket analogy: This is like missing a live stadium PA update because you stepped out to the concession stand — when you return, the PA doesn't repeat what you missed, it just continues broadcasting whatever happens next.
Never use Pub/Sub for data that must not be lost, such as order events that drive billing, or notifications a user absolutely must eventually receive. If you need at-least-once delivery, consumer groups, message replay, or durability across subscriber restarts, use Redis Streams (XADD/XREAD/XREADGROUP) instead, which persists messages in a log-like structure and supports acknowledgment-based consumption. Pub/Sub is the right tool only when losing a message during a disconnect is an acceptable trade-off, such as live cache-invalidation broadcasts or ephemeral presence updates.
Common Use Cases and Cluster Behavior
Typical legitimate uses include broadcasting cache-invalidation events to multiple application server instances so they can drop a local in-memory cache entry the instant it changes upstream, powering real-time features like live chat typing indicators or live dashboard updates where only the most current state matters, and implementing keyspace notifications, where Redis itself publishes events like expired or set to a special channel whenever a key changes, letting applications react to Redis-internal events. In Redis Cluster mode, regular PUBLISH/SUBSCRIBE messages are broadcast to every node in the cluster regardless of which node the publishing or subscribing client is connected to, while SPUBLISH/SSUBSCRIBE (sharded Pub/Sub, added in Redis 7) restrict propagation to the shard owning the channel's hash slot, reducing cross-node broadcast overhead for high-throughput use cases.
Cricket analogy: Cache invalidation broadcasts are like a stadium's giant screen operator instantly refreshing the scoreboard the moment DRS overturns a decision, so every screen around the ground updates in sync rather than each screen operator independently deciding when to refresh.
Redis's built-in keyspace notifications must be explicitly enabled with CONFIG SET notify-keyspace-events (they're off by default for performance reasons), and once enabled, Redis publishes to channels like __keyspace@0__:mykey and __keyevent@0__:expired so applications can subscribe to react to expirations, deletions, or other key events in real time.
- PUBLISH broadcasts a message to every current subscriber of a channel; there is no storage, queuing, or delivery tracking.
- A message published to a channel with no active subscribers is simply discarded; PUBLISH can legitimately return 0.
- PSUBSCRIBE allows glob-pattern subscriptions across multiple channels without knowing every exact channel name upfront.
- Pub/Sub is fire-and-forget: disconnected or slow subscribers permanently miss messages published during that window.
- Redis Streams (XADD/XREAD/XREADGROUP) should be used instead when durability, replay, or consumer groups are required.
- Keyspace notifications let Redis itself publish events like expired or set, but must be enabled via CONFIG SET notify-keyspace-events.
- In Cluster mode, plain PUBLISH broadcasts cluster-wide, while SPUBLISH/SSUBSCRIBE (Redis 7+) scope propagation to a single shard.
Practice what you learned
1. What happens to a message published with PUBLISH to a channel that has zero active subscribers?
2. What does PSUBSCRIBE allow that plain SUBSCRIBE does not?
3. If a subscriber disconnects for 10 seconds and reconnects, what happens to messages published during that gap?
4. Which Redis feature should be used instead of Pub/Sub when message durability and consumer groups are required?
5. In Redis Cluster mode, how does SPUBLISH differ from a regular PUBLISH?
Was this page helpful?
You May Also Like
Redis Transactions: MULTI/EXEC
Understand how Redis groups commands into atomic transactions using MULTI, EXEC, DISCARD, and optimistic locking with WATCH.
Key Expiration and TTL
Learn how Redis lets keys expire automatically using TTLs, and how expiration is implemented internally through lazy and active mechanisms.
Redis Key Naming Conventions
Understand why disciplined key naming matters in Redis and how to design namespaces that scale across teams and services.