Art of Codeartofcode
Lesson 5 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.4 What do we store?

3 min read+10 XP
notification_types type, category (security | transactional | marketing), channels allowed, priority, template ids per channel and language templates id, channel, language, version, body with placeholders preferences user_id, (category, channel) → opted in?, quiet hours, time zone, daily marketing cap, language devices user_id, push token, platform, last seen (tokens go stale, Chapter 21) notifications id, idempotency_key (unique), user_id, type, status per channel, provider message id, timestamps (the status store) otp phone, hmac(phone + code), expires_at, attempts (Redis, with TTL)

Interviewer pushback:

  • "Why store OTPs in Redis and not the database?" → They live for 5 minutes, are read once or twice, and need a TTL. Redis with a replica fits; a lost OTP means the user taps "resend".

Memory code: "Accept fast, deliver later; the OTP never leaves the building in plain text."