Question 8 · Track 3 · Deliver it to people
Design a notification system
One event in, three channels out, and nobody gets it twice.
Deliver it to people. 4 clarifying questions to ask first, the answer in 4 moves, the follow-up that catches a memorised answer and 3 supporting topics to watch or read.
Short answer live
What it is really testing
Whether you decouple producers from channels, and how you handle a retry that already succeeded.
Ask these first
Before a single box goes on the board. The answers change the design, which is the point of asking out loud.
- Which channels — push, email, SMS, in-app?
- How many notifications a day, and how peaky?
- Is ordering per user required, or is best-effort fine?
- Do users have quiet hours or preferences?
The answer, in 4 moves
In this order. Each move earns the next one — say them out loud rather than drawing all four and narrating afterwards.
- 1One central notification service every producer calls — never a producer per channel.
- 2A queue absorbs the burst so a spike never reaches the providers.
- 3Push, email and SMS are separate workers with their own retries and failure modes.
- 4Per-channel rate limits, plus a dedupe key so a retry cannot double-send.
The trap
The follow-up that separates a rehearsed answer from a real one.
Delivery is at-least-once whether you designed for it or not, so the idempotency key is yours to invent. Without one, every provider timeout becomes a second notification.
Watch or read
The pieces of this answer, each covered on its own. Take them whichever way suits you, then give the whole answer without looking.
Design a notification system, end to end
"Design a notification system" sounds like a feature question. It is an infrastructure question: is notification a shared service every producer calls, or code each service bolts on for itself? Here is the whole answer in four points — one central service, a queue that absorbs the burst, push/email/SMS as separate channels, and per-channel limits plus preferences — and the trap that fails candidates: not sending the same notification five times.
At-least-once vs exactly-once
A customer taps Pay once and gets charged twice — with no bug in your code. Delivery semantics from first principles: why a lost acknowledgement makes at-most-once, at-least-once and 'exactly-once' inevitable, and why exactly-once is a property of your consumer, not a setting on your broker.
Pub/sub vs API calls
A user signs up, and email, push, and analytics all need to know. Do you call each service yourself, or publish one event and walk away? Here's Pub/Sub vs direct API calls — event-driven async messaging vs synchronous request/response — with a clear rule for which one to reach for.
Part of System Design Interviews, Answered Out Loud. The fundamentals underneath it are the free CS course.