Notification System — System Design Interview

Phase 1: Clarify, Scope & Constraints

Interviewer: "Design a notification system. Users should receive notifications via push notifications, email, and SMS. Where do you start?"

Candidate: "Let me clarify scope first. 'Notification system' could mean many things — a first-party system for one product, or a platform that other services use as infrastructure. Can you tell me more about the use case? I want to focus on the most interesting design challenges."

Interviewer: "Think of it as a platform — like what Facebook or Uber might build internally. Other services publish events; the notification system delivers to users across channels."

Candidate: "Perfect — that's a much more interesting design. Let me identify the core user journeys:

1. Send: An upstream service (e.g., 'Friend Request Service') sends a notification event. The notification system routes it to the right channels for the recipient user.
2. Receive: A user gets a push notification on their phone, an email in their inbox, or an SMS on their phone.
3. Preferences: A user can opt out of specific notification types or channels (e.g., 'no SMS for marketing').
4. Tracking: Upstream services can query delivery status (sent, delivered, opened, failed).

What channels are in scope? I'll design for push (iOS/Android), email, and SMS — in that priority order for technical complexity."

Interviewer: "All three. What's the core complexity?"

Candidate: "There are two distinct hard problems here:

1. Fan-out at scale: A single event can trigger notifications to millions of users simultaneously (e.g., a breaking news alert, a…