Exercise ยท Communication
Notification System
Whiteboard exercise. Try the problem cold, then reveal the rubric to self-score.
Out of 10 points30 min whiteboardReference solution โ
01
Prompt
Design a notification system. Push (iOS/Android/web), SMS, email. 10M messages/sec peak. Per-user preferences. Delivery tracking.
Time budget: 30 min whiteboard. Draw architecture, estimate numbers, discuss tradeoffs.
02
Hints (progressive โ click to reveal)
Hint 1
Fan-out on a pub/sub (Kafka) โ decouple producers from per-channel delivery workers.
Hint 2
Per-channel worker pools (APNs, FCM, web-push, SMS, email) each with its own rate limits.
Hint 3
Dedup + preferences + throttling live in a central service before fan-out.
03
Rubric โ 10 points
- +2 Event-sourced via Kafka; producers emit notification-request; delivery workers consume per-channel
- +2 Per-channel worker pools (APNs/FCM/SMS/email) each obeying provider rate limits + retries
- +1 Central preferences service: user opt-in/opt-out per channel + notification type; filter before fan-out
- +1 Dedup by (user, notification_id) within TTL window to prevent duplicate delivery
- +1 Collapse / rate-limit notifications: '3 mentions in #general' beats 3 separate pushes
- +1 Token management: APNs/FCM tokens expire; cleanup pipeline from delivery errors
- +1 Delivery tracking: status DB (queued โ sent โ delivered โ clicked); expose via API
- +1 Priority lanes: transactional (auth codes) vs marketing; separate queues + SLAs
Self-score: tally the points you would have mentioned unprompted. 7+ is interview-ready on this problem.
04
Red flags (things that tank the interview)
- Synchronous notification in request path
- Single worker pool serves all channels (APNs throttle blocks everything)
- No preferences / opt-out handling (violates GDPR/CAN-SPAM)
- Doesn't clean up dead tokens (keeps sending to them, gets throttled)
- No dedup (sends same notification N times on retry)