Redis Pub/Sub is a live message fanout system. It is immediate, lightweight, and deliberately not durable.

The entire model can be summarized as:

publisher -> channel -> currently subscribed clients

If no client is subscribed when a message is published, the message is not stored for later. It disappears. That is not a limitation accidentally left unresolved; it is the feature boundary.

Channels Are Routing Names

A client subscribes to one or more channels:

SUBSCRIBE news sports

Another client publishes:

PUBLISH news "hello"

Redis finds the clients subscribed to news and appends a message reply to each of their output buffers. The publisher receives the number of clients that received the message.

Internally, the server needs an index shaped like:

type PubSubState = {
  channels: Map<string, Set<Client>>;
  patterns: Array<{ pattern: string; client: Client }>;
};

Pattern subscriptions add matching work, but the central idea is the same: publish finds interested clients and pushes messages to them.

Subscribed Clients Enter A Different Mode

After a client subscribes, the connection is no longer an ordinary request-response channel. It becomes a stream of pushed messages with a restricted command set.

This matters because Redis protocol usage changes shape. A normal client sends a command and expects one reply. A subscribed client may receive messages at any time as other clients publish.

The client lifecycle, not the keyspace, owns this mode. Pub/Sub does not store values under keys. It routes messages through connection state.

Pub/Sub Versus Lists And Streams

A list can be used as a queue. A producer pushes items, and consumers pop them. The items exist in Redis until removed.

A stream is an append-only log. Entries have IDs, can be read by range, and can be tracked through consumer groups.

Pub/Sub is different:

Pub/Sub: deliver now to listeners
List: store items until consumed
Stream: store ordered event history

If a user needs replay after reconnecting, Pub/Sub is the wrong tool. If a user needs very low-latency fanout to clients that are already online, Pub/Sub fits beautifully.

Output Buffers Are The Hidden Cost

Publishing one message to one client is easy. Publishing one message to 100,000 clients is a memory and scheduling event.

Each recipient gets a message appended to its output buffer. If some subscribers read slowly, their buffers grow. A hot channel can therefore turn slow clients into memory pressure.

This is why Pub/Sub clients need careful output-buffer limits. The server cannot let live fanout become unbounded memory growth.

Nothing Is Left Behind

The most important thing to remember about Redis Pub/Sub is where the message lives after PUBLISH returns. Usually, it lives only in client output buffers, kernel socket buffers, or client memory. It is not in the Redis keyspace.

That is what makes Pub/Sub fast and simple. It is not trying to be a durable broker. It is a live signal path.