33. Design a Notification System
1
The interview prompt2
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 yourself13
Variations to practise14
Sources15
Code lab33. Design a Notification System
33.2 How big is this, really?
3 min read+10 XP
Step 2: Estimates (5 minutes)
Assume about 300 bytes per status record, a peak factor of 5 for normal traffic, and 90 days of status history.
| What | Working | Result |
|---|---|---|
| Average notifications a second | 30 million ÷ 86,400 | ≈ 350 a second |
| Peak (normal traffic) | 350 × 5 | ≈ 1,750 a second |
| Campaign burst | 20 million emails ÷ 2 hours (7,200 s) | ≈ 2,800 emails a second |
| OTPs | 1.5 million a day; peak given | ≈ 17 a second average, ~300 peak |
| Status records | 30 million × 300 bytes | ≈ 9 GB a day, about 810 GB for 90 days |
| OTP stuck behind a campaign (one shared queue) | 2 million ahead ÷ 5,000 a second | ≈ 400 s: useless |
What the numbers say, out loud:
- "A few thousand a second at peak is easy for queues and workers. Throughput isn't the hard part."
- "The hard parts are isolation and correctness: an OTP must not queue behind 2 million emails, and retries must not send it twice."
- "Providers are the real limit: SMS and email providers cap our sending rate, so workers must respect those limits (Chapter 25)."
Interviewer pushback:
- "Where's the cost?" → SMS is the expensive channel, charged per message. Duplicate or unnecessary SMS cost real money; prefer push or email where the user allows it, and never send an SMS twice.
Memory code: "Volume is easy; isolation and duplicates are the job."