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 3: System Design & Interview Mastery
maang.io System Design Series
What is this?
You now know Redis Pub/Sub from the four verbs down to the single-threaded fan-out loop and the buffer limit that kills slow subscribers. This chapter is where that knowledge earns the offer. Interviewers don't want you to recite "Pub/Sub has no persistence" — they want to watch you reach for it at exactly the right moment, refuse it at the wrong one, and defend the choice when they push you toward Kafka. That's the senior signal.
We'll do two things: see where Pub/Sub fits in real designs (with diagrams), then run a mock interview — for each question, what they're really asking, a model answer, and the senior line that says you've operated this in anger.
The one-line idea: interviewers use Redis Pub/Sub to test whether you can tell a live signal from a durable event — reaching for the radio broadcast when losing a message is acceptable, and knowing the exact moment that stops being true and you must upgrade to a DVR (Streams or Kafka).
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