Design a Notification Service
Design a notification service for a social media platform. The service must deliver notifications to users via push (mobile), email, and in-app channels. Notifications are triggered by user events (likes, comments, follows, mentions). The system must be reliable, handle notification preferences, and avoid spamming users.
Requirements
- ✓Deliver notifications via push (APNs/FCM), email (SMTP/SES), and in-app channels.
- ✓Respect per-user notification preferences (enabled/disabled per type and channel).
- ✓Deduplicate: do not send duplicate notifications for the same event within a time window.
- ✓Batch low-priority notifications (e.g., group 5 likes into one notification).
- ✓Prioritize: deliver time-sensitive notifications (e.g., DM, security alert) with low latency.
Constraints & Scale
- —10 million daily active users; peak: 500,000 notification events/second.
- —Push delivery p99 < 5 seconds after event; email < 1 minute.
- —In-app notifications must be queryable (paginated history per user).
- —At-least-once delivery guarantee; tolerate duplicate delivery if deduplicated at receiver.
- —Support notification expiry (e.g., a 'like' notification older than 24 hours is stale).
Interactive Architecture Blueprint3 views
Visual topology, node responsibilities, traffic flow steps, and bottlenecks.
Break down the core challenges: fanout (one event → many notifications), preference filtering, deduplication, and delivery guarantees. Identify the main components before designing.
Main challenges: (1) Fanout — a single event (e.g., a post from a celebrity with 10M followers) generates millions of push notifications. (2) Preference filtering — each recipient has different opt-in/opt-out settings. (3) Reliability — ensure delivery even if a channel (push) is temporarily down. (4) Batching/rate limiting — avoid overwhelming users with dozens of individual notifications.
Trade-offs
- ⚖Push fanout synchronously: simple but blocks event processing and slows the platform.
- ⚖Message queue + async workers: decouples notification from event source; preferred pattern.
- ⚖Write fanout vs read fanout: write fanout (write to each recipient's inbox on event) is simple but expensive for celebrities; read fanout (compute on read) reduces writes but increases read latency.
Concepts used in this stage