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)