Redis Pub/Sub

Pub/Sub (Publish/Subscribe) is a messaging pattern where senders (publishers) send messages to named channels, and receivers (subscribers) listen to those channels. The publisher does not know who is listening, and subscribers do not know who sent the message. Redis works as the message broker in the middle.

The Radio Station Analogy

A radio station broadcasts on a frequency. Anyone who tunes their radio to that frequency hears the broadcast. The station does not know how many listeners are tuned in, and the listeners do not talk back. Redis Pub/Sub works exactly like this.

                    Redis (the broadcast tower)
                    ┌───────────────────────────┐
Publisher App ────▶ │  Channel: "alerts"        │ ────▶ Subscriber A
  ("Send alert!")   │  Channel: "orders"        │ ────▶ Subscriber B
                    │  Channel: "notifications" │ ────▶ Subscriber C
Publisher App ────▶ │                           │
  ("New order!")    └───────────────────────────┘

Subscribers receive only the channels they subscribed to.

Subscribing to a Channel

Open Terminal 1 and subscribe to a channel named "news":

127.0.0.1:6379> SUBSCRIBE news
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "news"
3) (integer) 1   ← subscribed to 1 channel

This terminal now waits. It cannot run other commands — it is in listening mode.

Publishing a Message

Open Terminal 2 and publish a message to the "news" channel:

127.0.0.1:6379> PUBLISH news "Redis 8.0 released!"
(integer) 1    ← 1 subscriber received the message

Back in Terminal 1, the message appears instantly:

1) "message"
2) "news"
3) "Redis 8.0 released!"

Subscribing to Multiple Channels

SUBSCRIBE news alerts orders

→ subscribed to 3 channels at once.
   Any message published to any of these three arrives here.

Pattern Subscriptions with PSUBSCRIBE

PSUBSCRIBE lets you subscribe to channels using a wildcard pattern. A single subscription matches many channels without naming them all individually.

PSUBSCRIBE order:*

This catches messages from:
  order:placed
  order:shipped
  order:cancelled
  order:refunded
  ... and any other channel starting with "order:"

Message received shows:
1) "pmessage"       ← pattern message (not regular message)
2) "order:*"        ← the pattern that matched
3) "order:shipped"  ← the actual channel name
4) "Order 9042 shipped to Jaipur"   ← the message content

Checking Active Pub/Sub State

List all active channels (that have at least 1 subscriber):
  PUBSUB CHANNELS

List channels matching a pattern:
  PUBSUB CHANNELS order:*

Count subscribers on a specific channel:
  PUBSUB NUMSUB news alerts
  → news 3 alerts 1   (3 listeners on news, 1 on alerts)

Count pattern subscriptions:
  PUBSUB NUMPAT
  → 2   (2 PSUBSCRIBE patterns active)

A Real Scenario – Live Notification System

App architecture:

  User places an order
       │
       ▼
  Order Service
  PUBLISH order:placed "{ orderId: 9042, userId: 501 }"
       │
       ├─────────────────────────────────────────────┐
       ▼                                             ▼
  Email Service                             Inventory Service
  (SUBSCRIBE order:placed)                  (SUBSCRIBE order:placed)
  Sends confirmation email                  Reduces stock by 1

  Both services act on the same event independently.
  Order Service does not know about them.
  Adding a new service (SMS, analytics) requires zero change to Order Service.

Important Limitations of Redis Pub/Sub

┌────────────────────────────────────────────────────────────┐
│  Limitation                                                │
├────────────────────────────────────────────────────────────┤
│  Messages are NOT stored. If a subscriber is offline       │
│  when the message is published, it never receives it.      │
│                                                            │
│  There is no delivery guarantee. If the network drops,     │
│  messages are lost.                                        │
│                                                            │
│  Subscribers cannot filter messages by content —           │
│  they receive everything on their channels.                │
│                                                            │
│  For reliable delivery with replay, use Redis Streams      │
│  (covered in Topic 13).                                    │
└────────────────────────────────────────────────────────────┘

Pub/Sub vs Task Queue (List)

┌──────────────────────┬──────────────────────┬──────────────────────┐
│  Feature             │     List Queue       │     Pub/Sub          │
├──────────────────────┼──────────────────────┼──────────────────────┤
│  Delivery            │  One worker gets it  │  All subscribers get │
│  Persistence         │  Stays until popped  │  Lost if no listener │
│  Multiple receivers  │  No (one pops it)    │  Yes (broadcast)     │
│  Best for            │  Job processing      │  Real-time events    │
└──────────────────────┴──────────────────────┴──────────────────────┘

Key Points

  • Publishers send messages to channels. Subscribers receive from channels. Neither knows about the other.
  • SUBSCRIBE listens to named channels. PSUBSCRIBE listens using wildcard patterns.
  • PUBLISH sends a message and returns the number of subscribers who received it.
  • Messages are fire-and-forget — offline subscribers never receive missed messages.
  • Use Pub/Sub for real-time broadcasting. Use Lists or Streams when you need reliable delivery.
Previous lessons
Back to courses
Next lessons

Leave a Comment