Art of Codeartofcode
Lesson 11 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.10 What would you say in the last five minutes?

3 min read+10 XP

Step 6: Wrap-up (5 minutes)

  • Bottlenecks: provider rate limits, not our servers. Covered by per-provider limits, separate quotas for OTP and bulk, and multiple providers.
  • Single points of failure: a single SMS provider (failover pair), the preferences store (cache with fallback to defaults for transactional messages), the queue (replicated).
  • Correctness: idempotency keys at the API, sent-records before every provider call, dead-letter queues with alerts.
  • Abuse and cost: OTP request limits, SMS pumping detection, and preferring push over SMS where allowed.
  • Next with more time: in-app notification inbox, A/B testing of templates, digests ("3 updates today") instead of 3 separate messages, and analytics on delivery and opens.

Memory code: "The provider is the bottleneck; the OTP is the priority; the duplicate is the bug."