Stop 14 · Real-time CommunicationTopics · 5/6

Pub/Sub Pattern

In short

When an order is placed, email, analytics and the warehouse all need to know. Pub/Sub lets the order service shout once without knowing who is listening.

A messaging pattern where publishers send messages to a channel without knowing who's listening, and subscribers receive messages from channels they're interested in — decouples senders from receivers.

The blob on a bicycle tosses rolled newspapers onto the balconies of three houses.

Think of it like this

The morning newspaper hawker

The newspaper office prints one edition. It doesn't know your flat number; the hawker has a list of subscribers and drops a copy at each. New reader? Just tell the hawker. The press doesn't change anything. Publishers publish, subscribers subscribe, the broker delivers.

Watch it happen

One publish, many listeners

Order service

Redis

Email svc

Analytics

SUBSCRIBE orders

1/5The email service tells Redis it wants every message on the orders channel.

The big ideas

What you need to know

Loose coupling

The publisher doesn't import or call the subscribers. Add a new listener without touching the order code.

Everyone gets a copy

Each subscriber receives every message on the channel. That's the difference from a work queue.

Redis Pub/Sub forgets

If a subscriber is offline when a message is published, it misses it forever. Use Streams or a queue if that matters.

Same idea, many tools

Redis, Kafka, Google Pub/Sub and AWS SNS all do pub/sub, with different guarantees about storage and delivery.

See it in code

Walk through the code

1import { createClient } from "redis";2 3const pub = createClient();4const sub = pub.duplicate();5await Promise.all([pub.connect(), sub.connect()]);6 7await sub.subscribe("orders", (message) => {8  console.log("email service got:", JSON.parse(message));9});10 11await pub.publish("orders", JSON.stringify({ id: 42, total: 499 }));

1/3A connection in subscribe mode can't run normal commands, so you make a second connection for it.

In real apps the publisher and subscriber live in different services. publish returns how many subscribers received the message, which is handy for debugging.

Save yourself the pain

Common mistakes

Oops

Using Redis Pub/Sub for payments or anything that must not be lost.

Do this instead

Pub/Sub is fire-and-forget. Use a durable queue or Redis Streams with acknowledgements for important work.

Oops

Running blocking commands on the subscriber connection.

Do this instead

Keep a separate client for normal reads and writes.

Your mission

Three terminals, one channel

~15 min

Quick check

Your analytics service restarts for 30 seconds. Orders published during that time over Redis Pub/Sub are:

Go deeper

1Implement pub/sub using Redis's `PUBLISH`/`SUBSCRIBE` commands.
2Use pub/sub to broadcast a WebSocket message across multiple server instances.
3Compare pub/sub to a message queue — pub/sub messages aren't persisted for offline subscribers.