System Design

Notification System

Design a multi-channel notification system (push, email, SMS).

Functional requirements

• Internal services submit notification requests via an API, specifying the recipient(s), message content/template, and priority (e.g., transactional/OTP vs. marketing/digest).
• The system delivers each notification over one or more channels (push, email, SMS) based on the notification type and per-user channel preferences and opt-outs.
• The same logical notification must not be delivered to a user more than once per channel, even if the calling service retries its request.
• Support bulk/broadcast sends (e.g., a marketing campaign to millions of users) alongside individual event-driven notifications.
• Track delivery status per notification per channel (queued, sent, delivered, failed) and expose it to calling services for querying.

Non-functional requirements

• High availability for the ingestion API (target 99.99%); accepting a notification request must never block on downstream provider health.
• At-least-once delivery semantics internally, with deduplication so users effectively see at-most-once per channel; no notification silently dropped after acceptance (durable once acked).
• Latency SLO by priority: critical notifications (OTP, security alerts) delivered end-to-end in < 5 seconds p99; marketing/digest notifications may take minutes.
• Graceful degradation when a third-party provider (APNs, email/SMS gateway) is slow or down: retries, failover, and no head-of-line blocking of other traffic.
• PII in messages (phone numbers, emails, content) must be encrypted at rest and access-controlled; respect regulatory opt-outs (e.g., SMS unsubscribe).

Scaling & constraints

• 300 million registered users; roughly 50 million DAU receiving at least one notification per day.
• Steady-state input: ~500 million notification requests/day from ~40 internal services; a single marketing campaign can inject 100 million recipients within a 1-hour window.
• Channel mix roughly 70% push, 25% email, 5% SMS; average message payload ~1 KB, delivery-status record ~500 bytes.
• Third-party provider rate limits: SMS gateway caps at ~5,000 msgs/sec, email provider ~50,000 msgs/sec; push is effectively unbounded but has per-device token churn (~2% of tokens invalid daily).
• Retain delivery status and audit history for 90 days; message templates and user preferences grow slowly (< 1 GB total).
• Traffic is bursty: peak (campaign + organic) can be 20x average per-second rate.

Out of scope

• Building the actual push/email/SMS gateways (assume third-party providers such as APNs, FCM, SendGrid-like, Twilio-like, with the stated rate limits).
• Template authoring UI and A/B testing of message content.
• In-app notification inbox / feed rendering.
• Analytics beyond basic delivery-status tracking (open rates, click attribution).