Art of Codeartofcode
Lesson 13 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

Variations to practise

3 min read+10 XP

Chapters used

Approach (1), Estimation (2), Polling vs push, APNs/FCM (21), Message queues (22), Pub/sub (23), APIs, idempotency and webhooks (24), Rate limiting (25), Failures and bulkheads (29), Observability (30).

Try these variations

Each is a common follow-up. Answer in two minutes, then check the sketch.

  1. "Add an in-app inbox." → Write every notification to an inbox store per user (paginated with cursors, Chapter 24); push becomes a nudge to open it.
  2. "Batch them into a daily digest." → Hold low-priority notifications in a per-user buffer; a scheduler renders one digest at the user's preferred time.
  3. "Support WhatsApp as a channel." → Another channel queue and worker with its own provider, templates approved in advance by the provider, and opt-in rules.
  4. "10× OTP traffic during a big launch." → Pre-warm OTP workers, raise provider quotas in advance with both providers, and offer non-SMS options to reduce load.