Design a Notification System

How to Use This Playbook

This playbook supports three reading modes:

What This Interview Actually Tests

Notifications is not a "send a push notification" question. Everyone can call the FCM API.

This is a delivery reliability and user experience ownership question that tests:

• Whether you separate notification generation from delivery routing (and who owns each)
• Whether you design suppression and deduplication as first-class features, not afterthoughts
• Whether you reason about notification fatigue as a product metric, not just a UX complaint
• Whether you can own the operational cost of multi-channel delivery at scale

The key insight: The hardest problem in notifications isn't delivery — it's deciding what not to send. Staff engineers design systems where suppression logic is as well-designed as delivery logic.

The L5 vs L6 Contrast (Memorize This)

The Three Intents (Pick One and Commit)

🎯 Staff Insight: "I'll assume we're building a notification platform that handles both transactional and engagement notifications. Transactional messages (order confirmations, password resets) have a 99.9% delivery SLA within 60 seconds. Engagement notifications (social activity, recommendations) are subject to user preferences, suppression rules, and batching. I'll focus on the architecture that separates these concerns."

The Five Fault Lines (The Core of This Interview)

1. Delivery Guarantee vs User Experience — Retrying aggressively ensures delivery but risks duplicates and annoyance. How do you balance reliability with user happiness?

2. Channel Routing — Push, email, SMS, in-app — each has different reliability, cost, and user impact. Who decides which channel, and what's the fallback chain?

3. Suppression & Rate Limiting — The most important feature users never see. How do you prevent notification fatigue without losing critical messages?

4. Priority & Ordering — Password resets must beat marketing emails in the queue. How do you prioritize without starving lower-priority notifications?

5. Delivery Tracking & Observability — How do you know a notification was actually received (not just sent)? Who owns delivery metrics?

Each fault line has a tradeoff matrix with explicit "who pays" analysis. See §3.

Quick Reference: What Interviewers Probe

Jump to Practice

→ Active Drills (§7) — 8 practice prompts with expected answer shapes

System Architecture Overview

Interview Walkthrough

Phase 1: Requirements & Framing (30 seconds)

• "Notification systems deliver messages across multiple channels — push (APNs/FCM), email, SMS, in-app — based on user preferences, urgency, and content type. The hard part isn't sending notifications; it's deciding WHAT to send, to WHOM, through WHICH channel, and WHEN."

Phase 2: Core Entities (30 seconds)

• NotificationEvent: the trigger — what happened (order shipped, friend request, price drop)
• NotificationPreference: per-user, per-category channel preferences (push for messages, email for receipts, no SMS)
• DeliveryChannel: the transport — APNs, FCM, SendGrid, Twilio, in-app websocket
• NotificationLog: immutable record of what was sent, when, through which channel, and the delivery status

Phase 3: The 2-Minute Architecture (2 minutes)

Phase 4: Transition to Depth (15 seconds)

"The pipeline is straightforward. The hard problems are: notification fatigue (sending too many), delivery reliability across channels, and real-time vs batched delivery."

Phase 5: Deep Dives (5-15 minutes if probed)

Probe 1: "How do you prevent notification fatigue?" (3-5 min)

"The biggest failure mode of a notification system isn't failed delivery — it's successful delivery of too many notifications. Users disable notifications, and you permanently lose the channel."

Walk through the mitigation:

1. Per-user daily budget: Maximum N notifications per day per channel. Priority-based: if the budget is 5 and 6 notifications are pending, drop the lowest-priority one.
2. Notification scoring: Each notification gets a relevance score based on: user's historical engagement with this category, recency of similar notifications, content relevance. Low-scoring notifications are suppressed.
3. Batching/digest: Instead of 10 individual "someone liked your post" notifications, batch them into one: "15 people liked your post." The batch window is time-based (every 30 minutes) or count-based (every 5 similar events).
4. Smart timing: Don't send notifications at 3 AM. Predict the user's active hours from historical app usage and queue notifications for their next active window.

Probe 2: "How do you handle delivery reliability?" (3-5 min)

"Each channel has different delivery guarantees:"

• Push (APNs/FCM): Fire-and-forget. APNs returns a success/failure immediately, but 'success' means 'Apple accepted it' — not 'the user saw it.' The device may be offline. "APNs gives you device tokens. If the token is invalid (user uninstalled), APNs tells you — update your device registry."
• Email (SendGrid/SES): Delivery confirmation via webhook (delivered, bounced, opened, clicked). Bounce handling is critical — hard bounces must immediately unsubscribe the address.
• SMS (Twilio): Delivery receipts available but not universal (depends on carrier). SMS is expensive ($0.01-$0.05/message) — use only for high-urgency notifications.
• In-app: WebSocket push if the user is online; persist to an in-app inbox for later viewing if offline.

Probe 3: "How do you handle multi-channel delivery?" (3-5 min)

"A high-urgency notification (fraud alert) should try multiple channels: push first, then SMS if push fails, then email. A low-urgency notification (weekly digest) goes to email only."

Walk through the cascade:

1. Primary channel: Based on user preference and notification type. Try push first.
2. Fallback on failure: If push fails (device token invalid or user didn't engage within 5 minutes), try the next channel in the cascade.
3. Deduplication: If the user sees the push notification, cancel the pending SMS/email. "The notification system must track cross-channel delivery and suppress duplicates."

Phase 6: Wrap-Up

"Notification systems are a restraint engineering problem. The technology (Kafka, APNs, SendGrid) is commodity. The Staff-level insight: the system's most important function is deciding NOT to send. Frequency caps, notification scoring, smart timing, and batching — these are the features that determine whether users keep notifications enabled or disable them forever."

Quick-Reference: The 30-Second Cheat Sheet