Score yourself

Give yourself 0, 1 or 2 points per row.

Area	0 points	1 point	2 points
Requirements	Started drawing	Listed channels	Channels, categories, latency per type, duplicates and opt-outs agreed
Estimates	None	Numbers, not used later	Numbers that showed isolation and provider limits are the real problems
API and data	Skipped	API or tables, not both	Async 202 API with idempotency key, OTP API separate, preferences and status modelled
High-level design	One queue, one worker	Queues and workers, no walkthrough	Order and OTP paths walked, receipts, campaigns separate
Deep dive	Hand-waved	One topic covered	Isolation, de-duplication, preferences or OTP security done properly
Trade-offs	None named	Named when asked	Raised unprompted (failover vs duplicates, SMS cost, priority vs separate queues)
Communication	Long silences	Mostly clear	Thought out loud, checked in, managed time

12 to 14: strong hire signal. 8 to 11: solid, polish the weak rows. Under 8: redo the round in a week, timer on.

The bar: fresher vs SDE-2

	Fresher	SDE-2
Channels	Queue plus workers per channel	Separate lanes by priority with reserved provider quotas
Reliability	Retries	Backoff, failover, DLQ, staleness checks
Duplicates	Not mentioned	Idempotency at API, worker and provider
Preferences	Opt-out flag	Categories, quiet hours by time zone, caps, unsubscribe rules
OTP	Random 6 digits in a table	Crypto RNG, HMAC, TTL, attempts, resend limits, fraud, SMS weaknesses

Common mistakes

One queue for everything, so a campaign delays OTPs.
Retrying by failing over to a second provider for every timeout, sending duplicates.
Storing OTPs in plain text, or letting the calling service generate and log them.
Applying marketing opt-outs to security messages, so users can't log in.
Ignoring provider limits and cost, especially for SMS.

Quick check

Five questions on this chapter. Pick an answer, then check it.

quiz

1[
2 {
3  "q": "A 2-million-user marketing campaign is sending. Why must OTPs use a separate queue?",
4  "options": [
5   "OTPs are larger",
6   "Otherwise OTPs wait behind the campaign and arrive after they expire",
7   "Campaigns are encrypted",
8   "Queues can't mix"
9  ],
10  "answer": 1,
11  "explain": "The OTP never stands in the campaign's queue."
12 },
13 {
14  "q": "How should an OTP be stored?",
15  "options": [
16   "Plain text for fast checks",
17   "Hashed, short-lived, single-use, with limited attempts",
18   "In the SMS log",
19   "In a cookie"
20  ],
21  "answer": 1,
22  "explain": "Random, hashed, short-lived, single-use, and sent through its own door."
23 },
24 {
25  "q": "A provider times out after possibly sending. How do you avoid a duplicate message on retry?",
26  "options": [
27   "Don't retry",
28   "Retry with the same idempotency key and skip what's already recorded as sent",
29   "Send to a second provider too",
30   "Ask the user"
31  ],
32  "answer": 1,
33  "explain": "Retry with the same key, skip what's already sent, drop what's gone stale."
34 },
35 {
36  "q": "A user turned off marketing emails. Which still goes out?",
37  "options": [
38   "A sale announcement",
39   "A security alert like \"new login on your account\"",
40   "A newsletter",
41   "Nothing"
42  ],
43  "answer": 1,
44  "explain": "Security always goes, transactions choose the channel, marketing asks permission."
45 },
46 {
47  "q": "What's usually the real bottleneck in a notification system?",
48  "options": [
49   "The database",
50   "The external providers' rate limits (SMS, email, push)",
51   "The API servers",
52   "DNS"
53  ],
54  "answer": 1,
55  "explain": "The provider is the bottleneck; the OTP is the priority; the duplicate is the bug."
56 }
57]

33. Design a Notification System

Score yourself

Score yourself

The bar: fresher vs SDE-2

Common mistakes

Quick check

Platform

Company

Legal