Art of Codeartofcode
Lesson 9 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.8 How do user preferences work?

3 min read+10 XP

Every notification has a category, and the rules differ:

CategoryExamplesPreferences apply?
SecurityOTP, password reset, new-device loginNo: always sent, on the channel the flow needs
TransactionalOrder shipped, payment failedChannel choice yes; full opt-out usually no
MarketingSale announcements, recommendationsYes: opt-in per channel, quiet hours, daily cap, one-click unsubscribe

The decision function in the chapter's code:

  • An order update goes to push and email (the channels Asha opted into), not SMS.
  • A promo at 23:00 her local time is held for 08:00 (quiet hours, in the user's time zone).
  • A third promo in a day is dropped (daily cap of 2).
  • An OTP at 3 a.m. goes out regardless.

Also:

  • Unsubscribe must be easy and fast. For email, Gmail and Yahoo's 2024 rules for bulk senders require authenticated mail (SPF, DKIM, DMARC), one-click unsubscribe honoured within two days, and spam complaint rates below 0.3%.
  • Preferences are read on every send: cache them, with invalidation on change.
  • Respect the law where users live (consent rules for marketing differ by country).

Memory code: "Security always goes, transactions choose the channel, marketing asks permission."