Redis Pub/Sub
maang.io System Design Series
Redis Pub/Sub offers dead-simple channel messaging: subscribers listen, publishers send, and Redis fans out instantly. The catch is it's fire-and-forget with no persistence — a disconnected subscriber misses messages (at-most-once). Knowing exactly where that's fine (live notifications, chat, cache invalidation) and where you need Redis Streams or Kafka instead is the whole lesson.
This deep dive comes in three parts:
- Foundations & Core Concepts — channels, pattern subscriptions, and fire-and-forget delivery.
- Internals — sharded pub/sub, and Redis Pub/Sub vs Streams vs Kafka, with worked examples.
- Interview — Staff/Principal Q&A: its hard limits and when to reach for a durable log.
Redis Pub/Sub — Part 2: Internals & The Publish Path
maang.io System Design Series
What is this?
Back to our radio station. In Part 1 we stood outside and watched broadcasts go out. Now we walk into the transmitter room and see the actual switchboard: a wall of labelled frequencies, a patch cord from each frequency to every listener tuned to it, and one operator working the whole board by hand, one action at a time. When a song comes in for 98.5 FM, the operator finds that frequency's row, runs down its list of patch cords, and pushes the audio down each one — then moves to the next job. There's no team; it's one operator, and how fast the board runs depends entirely on how many cords are plugged in.
That single operator is the key to everything in this chapter: Redis executes commands on one main thread. A PUBLISH is not magic fan-out hardware — it's a loop, run by that one thread, that walks a list of subscribers and copies the message to each. Once you internalise that, the performance profile, the failure modes, and the reason sharded Pub/Sub exists all become obvious.
The one-line idea: A
PUBLISHis a synchronous, single-threaded loop over the channel's current subscribers (plus a scan of every registered pattern). Cost is O(N + M) — N subscribers on the channel, M patterns registered server-wide — and it all happens inline, on the same thread that serves every other command. Nothing is queued, nothing is stored, nothing is retried.
Let's open the two data structures the whole thing runs on, then follow a message through.
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson