Pub/Sub

Pub/Sub is a messaging pattern that shows up a lot in system design interviews.

It solves the problem of broadcasting events to multiple services without tight coupling, such as sending chat messages to multiple users, pushing notifications to connected clients, or updating live dashboards in real time.

Redis is one of the most common technologies used to implement Pub/Sub. But how does it work under the hood?

What is Pub/Sub?

It’s a messaging pattern where publishers send messages to channels, and subscribers receive messages from those channels. Publishers and subscribers don’t need to know about each other.

Redis provides a simple implementation: PUBLISH sends a message, and SUBSCRIBE listens for messages. Behind those commands is a direct, in-memory delivery mechanism.

How does it work?

Redis keeps a dictionary mapping each channel name to a list of subscribed clients. When you call PUBLISH, Redis looks up the channel and writes the message to each subscriber’s output buffer.

The output buffer is a region of memory Redis uses to hold outgoing data before it’s sent over the TCP socket. Once the subscriber’s client reads from the socket, the message leaves the buffer, usually within milliseconds if the client is responsive.

What happens if a subscriber is slow?

If a subscriber’s network or processing speed is slow, its output buffer fills up. Redis enforces memory limits on this buffer. When the limit is exceeded, Redis disconnects the client. It doesn’t retry or queue messages, it immediately moves on to other subscribers.

From the publisher’s perspective, PUBLISH still returns success, but the slow subscriber misses any messages published while it’s disconnected.

These results in important trade-off discussions.

Redis Pub/Sub prioritizes throughput and simplicity. There is no persistence, message history, or delivery acknowledgment. It just immediately forwards in memory on Redis’s single thread.

That makes it ideal for ephemeral, high-frequency updates such as chat messages, notifications, or presence updates where occasional message loss is acceptable.

If you need durability, replay, or guaranteed delivery, use Redis Streams instead. Streams persist messages, support consumer groups, and allow message acknowledgment and replay.