Katkat
Back

Design a Multi-Channel Notification System

PinterestSoftware Engineer · Online Assessment
MediumSoftware EngineerOnline AssessmentSystem Design

Last updated

Design an extensible, resilient multi-channel notification engine (push, email, SMS, in-app) supporting high throughput, deduplication, quiet hours, rate limiting, and provider fallbacks.

Scenario

A visual discovery platform with over 500 million monthly active users needs a centralized notification platform. The system must dispatch personalized alerts—ranging from immediate security codes to engagement updates (e.g., "Someone saved your Pin") and promotional digests—across multiple delivery channels (Mobile Push, Email, SMS, and In-App inbox).

Requirements

Functional Requirements

  • Multi-channel routing: Support Push (APNS/FCM), Email, SMS, and In-App notifications.
  • User preferences and quiet hours: Respect user-defined category opt-outs, preferred delivery channels, and local-time quiet hours (e.g., defer non-critical alerts between 10 PM and 8 AM).
  • Frequency capping and deduplication: Enforce rate limits per user (e.g., at most 3 push notifications per hour) and drop or coalesce duplicate events sent within a short sliding window.
  • Priority and fallback: Support priority tiers (CRITICAL, DEFAULT, LOW). If a high-priority push notification fails to deliver or register, trigger an automated fallback (e.g., push -> SMS/email).
  • Auditing and status tracking: Track each notification lifecycle (ACCEPTED, SUPPRESSED, ENQUEUED, SENT, DELIVERED, FAILED, READ) via delivery receipt webhooks from external vendors.

Non-Functional Requirements

  • Scale: 2 billion notifications per day; peak ingestion traffic of 50,000 requests/second.
  • Latency: Critical alerts (2FA, security) delivered within 5 seconds end-to-end. Marketing/engagement digests can tolerate minutes of delay.
  • Reliability: At-least-once delivery for critical alerts. Strong idempotency to prevent spamming users upon internal service retries.

What Your Design Should Cover

  1. API Design: Endpoints for upstream services to trigger notifications and for users to manage preferences.
  2. Data Model: Schemas for notification intents, user preferences/devices, and delivery audit logs.
  3. System Architecture: Detailed message flow from ingestion, preference evaluation, template rendering, and priority queuing, to channel-specific worker pools and webhook consumers.
  4. Trade-offs and Edge Cases: Handling upstream provider outages, dynamic queue throttling, token invalidation (e.g., bad APNS tokens), and quiet hour scheduling.

Hints

Hint 1

Decouple ingestion from dispatch by accepting requests asynchronously with an idempotency key and writing immediately to an append-only log or distributed message queue.

Hint 2

Evaluate user quiet hours and sliding-window frequency caps using a fast in-memory store like Redis before passing messages to template rendering and provider dispatchers.

Hint 3

Use dedicated, prioritized queues for critical alerts versus bulk marketing to prevent low-priority backlogs from starving time-sensitive notifications like 2FA codes.

Follow-up questions

  • How would you implement notification aggregation/bundling (e.g., turning 10 individual 'liked your Pin' events into a single notification) without adding significant delay?
  • How does the system gracefully handle a catastrophic multi-hour outage of an external provider like Apple Push Notification Service (APNS) or Twilio?
  • How would you design the database and caching layer to verify user quiet hours and device registration tokens across hundreds of millions of users without creating hot keys?