How does Redis Pub/Sub work?

Question

Accepted Answer

**Pub/Sub** (Publish/Subscribe) is Redis's messaging pattern where **publishers** send messages to **channels** and **subscribers** receive messages from channels they're subscribed to — without publishers and subscribers knowing about each other. It enables real-time messaging and decoupled communication between services.

## The Pub/Sub model

```bash
# Subscriber listens on a channel
SUBSCRIBE news                    # subscribe to the "news" channel

# Publisher sends a message to the channel (in another connection)
PUBLISH news "Breaking story!"    # all subscribers to "news" receive this instantly

# Pattern subscriptions (wildcards)
PSUBSCRIBE news.*                 # subscribe to news.sports, news.tech, etc.
```

Publishers `PUBLISH` to a channel; subscribers `SUBSCRIBE` to channels and receive messages in real time. They're **decoupled** — the publisher doesn't know who (if anyone) is listening.

## Use cases

```text
✓ REAL-TIME notifications — push events to interested services/clients instantly
✓ Chat / messaging — broadcast messages to subscribers
✓ Live updates — dashboards, feeds, multiplayer (broadcast state changes)
✓ Decoupling services — services communicate via channels without direct coupling
✓ Often paired with WebSockets (Redis pub/sub → server → WebSocket → browser)
```

## Important limitation: fire-and-forget

```text
⚠️ Redis Pub/Sub is FIRE-AND-FORGET (at-most-once delivery):
  → Messages are delivered ONLY to subscribers connected AT THAT MOMENT.
  → If a subscriber is offline/disconnected, it MISSES the message (no storage/replay).
  → No persistence, no acknowledgment, no delivery guarantee.
→ NOT suitable when you need reliable delivery or message history.
```

## When you need reliability: use Streams

```text
For RELIABLE messaging (persistence, replay, consumer groups, acknowledgments):
  → use Redis STREAMS (a durable, log-based structure) instead of Pub/Sub
  → or a dedicated message broker (Kafka, RabbitMQ)
Pub/Sub → simple real-time broadcast where missing messages is acceptable
Streams → when you need durability and delivery guarantees
```

## Why it matters

Understanding Redis Pub/Sub is valuable for **real-time messaging and decoupled communication**, so it's useful knowledge — but critically, understanding its limitations is equally important to use it appropriately.

Pub/Sub enables **real-time messaging** where publishers broadcast to channels and subscribers receive instantly, with publishers and subscribers **decoupled** (unaware of each other) — powering use cases like real-time notifications, chat, live dashboard updates, and decoupled service communication (often paired with WebSockets to push updates to browsers).

This makes Redis a simple, fast option for real-time broadcast features.

However, the **most important point** is understanding Pub/Sub's **fire-and-forget limitation**: it's at-most-once delivery — messages reach only subscribers connected at that moment, and offline subscribers **permanently miss messages** (no persistence, replay, acknowledgment, or delivery guarantee).

This is a crucial constraint: Pub/Sub is unsuitable when reliable delivery or message history matters, and not understanding this leads to lost-message bugs.

Knowing the alternatives — **Redis Streams** (durable, log-based, with consumer groups and acknowledgments) or dedicated brokers (Kafka, RabbitMQ) for reliable messaging — and choosing Pub/Sub only for simple real-time broadcast where missing messages is acceptable reflects sound judgment.

Since real-time messaging is a common need, and since Redis Pub/Sub provides a simple solution for it but with important reliability limitations (requiring Streams or a broker when guarantees are needed), understanding Pub/Sub — how it works, its use cases, and especially its fire-and-forget limitation and when to use Streams instead — is valuable, practically-relevant knowledge for implementing real-time features correctly, where understanding the limitation is as important as understanding the capability.