Design a Notification Service

Problem Design a general notification service delivering messages to users across email, SMS, and push.

Functional requirements

• Producer API: notify(userId | audience, template, payload, channel preferences/fallbacks, priority).
• User preference management (opt-outs per channel/category); templating with localization; delivery-status tracking and callbacks.

Non-functional requirements

• Scale to discuss: ~10K notifications/sec sustained, bursty campaigns 10x; p99 enqueue latency < 50 ms (delivery is async).
• At-least-once delivery with dedupe; no notification loss on component crash.

Key components

• Ingest API → validation/preference filter → message queue (partitioned by user for per-user ordering) → channel workers (EmailSender, SmsSender, PushSender behind one interface) → provider integrations with per-provider rate limiters → delivery-receipt handler updating a status store; retry queues + DLQ; template service.

Deep dives / trade-offs

• Retries and idempotency: exponential backoff, dedupe key (notificationId) so provider retries don't double-send; DLQ replay.
• Rate limiting per provider and per user (don't spam one user from parallel campaigns); priority lanes so OTPs beat marketing.
• Fan-out for broadcast campaigns: materialize per-user messages at enqueue vs expand at worker; storage and spike implications of each.