Art of Codeartofcode
Lesson 2 of 15

33. Design a Notification System

1
The interview prompt
2
33.1 What do you ask first?
3
33.2 How big is this, really?
4
33.3 What are the doors?
5
33.4 What do we store?
6
33.5 What does the whole system look like?
7
33.6 Why one queue per channel?
8
33.7 How do retries and de-duplication work?
9
33.8 How do user preferences work?
10
33.9 What makes OTPs special?
11
33.10 What would you say in the last five minutes?
12
Score yourself
13
Variations to practise
14
Sources
15
Code lab
33. Design a Notification System

33.1 What do you ask first?

3 min read+10 XP

Step 1: Requirements (5 minutes)

LetterCandidate asksInterviewer answers
Scope"Which channels? Do users choose what they get? Templates and languages? Scheduled campaigns? Do we need delivery status?""Push, SMS, email. Users can opt out of marketing. Templates in a few languages. Campaigns yes. Track sent, delivered, failed."
Count"How many users and notifications a day?""20 million users. About 30 million notifications a day; a big sale campaign can add 20 million emails in a couple of hours."
Access pattern"How many are OTPs? Any peaks?""Around 1.5 million OTPs a day, peaking at a few hundred a second in the evening."
Latency"How fast must each type arrive?""OTPs within seconds. Order updates within a minute. Marketing whenever, within the day."
Exactness"Can a user ever get the same notification twice? Can one be lost?""Duplicates are annoying, and SMS costs money. A lost OTP means a lost login. Neither is OK."

Agreed requirements:

  • Functional (verbs): services send a notification to a user by type; the system chooses channels from preferences, renders templates, delivers via providers, tracks status; users manage preferences; marketing schedules campaigns.
  • Non-functional (adjectives): OTPs fast (within ~10 s end to end, most within a few seconds) and isolated from bulk traffic; reliable (at-least-once delivery, no silent loss); no duplicates to users; respectful (opt-outs, quiet hours, frequency caps); secure for OTPs; scalable for campaign bursts.

Interviewer pushback:

  • "Why do you treat OTPs differently from the start?" → They have the tightest deadline, they're security-sensitive, and they must never wait behind a marketing blast. That decides the queue design (33.6).
  • "Exactly-once delivery?" → Not over a network (Chapter 22). At-least-once internally, plus de-duplication with idempotency keys before we call a provider, gives "the user sees it once" in practice.

Memory code: "Ask which messages can't be late, can't repeat, and can't leak."