Publish–Subscribe Pattern
maang.io System Design Series
The publish–subscribe pattern decouples senders from receivers through topics: producers publish without knowing who listens, and the broker fans each message out to every subscriber. It's the shape behind event-driven architectures, notifications, and cache invalidation — and understanding push vs pull and durable vs ephemeral subscriptions is what separates a working design from a lossy one.
This deep dive comes in three parts:
- Foundations & Core Concepts — topics, fan-out, and pub/sub vs point-to-point.
- Internals — push vs pull, durable subscriptions, and filtering/routing, with worked examples.
- Interview — Staff/Principal Q&A: fan-out at scale and choosing a broker.
Publish–Subscribe Pattern — Part 3: System Design & Interview Mastery
maang.io System Design Series
What is this?
You now know pub/sub from the topic down to the broker's cursor. This chapter turns that into an offer. Interviewers don't want you to recite "pub/sub decouples producers from consumers" — they want to watch you reach for it at the right moment, wire it into a design, and defend the trade-offs when they push: "What if a subscriber is slow? How do you avoid duplicates? Why not just call the services directly?"
We'll do two things: first 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 signals you've built this for real.
The one-line idea: interviewers use pub/sub to test whether you can turn a tightly-coupled call graph into an event-driven system — one publisher, many independent reactions — and then live honestly with the costs: eventual consistency, duplicate delivery, ordering limits, and slow-consumer lag.
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