Design Notification System

LinkedIn system design interviews often feature "Design Notification System" as a key question, focusing on scalable, multi-channel delivery (email, SMS, push) with real-time guarantees. No single official "full problem statement" exists publicly from LinkedIn, but it's consistently framed around handling massive scale for a professional network, incorporating backend services, web APIs, messaging queues, ML-driven prioritization, and rate limiting.[1][2]

Core Problem Statement

Design a highly available notification system for LinkedIn-scale (1B+ users) that reliably delivers personalized notifications across channels like push, email, SMS, and in-app. Key goals include low-latency delivery (<5s for critical types like OTPs), fault tolerance (guaranteed delivery despite outages), user preferences (opt-in/out by type/channel), and scalability to millions of notifications per minute during peaks.[2][6][1]

Functional Requirements

• Triggering: Accept notifications via API from services (e.g., new connection, job match, message).
• Personalization: Use ML for ranking/prioritization (e.g., relevance scores based on user connections, activity).[1]
• Multi-channel: Route to push (FCM/APNs), email, SMS, in-app based on user prefs.
• Status tracking: Report states (queued, sent, delivered, read, failed) with idempotency.[3][5]
• Retries/DLQ: Exponential backoff for failures, dead letter queues for persistent issues.[2][3]

Non-Functional Requirements & Constraints

• Scale: 100M+ daily active users; peaks at 10M+ notifications/minute (e.g., flash events).[6]
• Latency: <100ms API acceptance; <5s end-to-end for high-priority.[2]
• Availability: 99.99% uptime with multi-region failover.[3]
• Rate Limiting: Per-user (e.g., 5/day total, 3/week promotional); per-client (10 reqs/sec); global throttling.[4]
• Storage: 1KB/notification; retain 30 days (~10PB for scale); user prefs (~100B entries).[2]
• Data: GDPR-compliant; no PII until delivery; idempotency keys to dedupe.[5]

Input/Output Examples

No standardized I/O formats from LinkedIn, but common API specs from interview discussions:

Send Notification (POST /v1/notifications)
Input: { "idempotency_key": "uuid-123", "user_id": "user123", "type": "JOB_RECOMMENDATION", // e.g., PROMO, OTP, TRANSACTIONAL "priority": "HIGH", "channels": ["PUSH", "EMAIL"], "template_id": 456, "params": {"job_title": "Engineer", "company": "LinkedIn"} } Output: {"notification_id": "notif-uuid", "status": "ACCEPTED"}.[5]

Status Check (GET /v1/notifications/{id})
Output: { "id": "notif-uuid", "status": "DELIVERED", "channel_status": {"PUSH": "DELIVERED", "EMAIL": "SENT"}, "timestamp": "2026-02-02T04:23:00Z" } .

Key Components

Typical architecture: API Gateway → Rate Limiter → Queue (Kafka/SQS partitioned by user_id) → Workers (prioritize via ML) → Channel Services (with retries) → Analytics.[6][3][2]