# Design a Multi-Channel Notification System Design a notification platform that accepts product events and delivers timely messages through channels such as push, email, SMS, and in-app inbox. Respect user preferences, prevent unwanted duplicates, and remain useful when providers or downstream systems fail. ### Constraints & Assumptions - Producers submit a notification intent with recipient, type, content parameters, priority, and idempotency key. - Users can configure channel preferences, quiet hours, locale, and opt-outs. - Some notifications are urgent while others may be grouped or delayed. - Third-party channel providers can time out, throttle, reject, or later report delivery status. - Exactly-once physical delivery cannot be guaranteed across every external provider. ### Clarifying Questions to Ask - Which channels, notification types, latency objectives, and delivery guarantees are required? - Who owns templates and localization, and may content change after enqueueing? - Which legal consent, opt-out, retention, and regional rules apply? - Should similar notifications be batched, collapsed, ranked, or rate-limited? - What does the product consider sent, delivered, read, or failed? ### Hints - Separate intent acceptance, policy resolution, rendering, channel delivery, and status tracking. - Snapshot enough policy and template information to make retries explainable. - Make each channel attempt idempotent where provider capabilities allow it. ### What a Strong Answer Covers - API contract, authentication, idempotency, durable intent storage, queues, and scheduling. - Preference, consent, quiet-hour, priority, frequency-cap, suppression, and fallback decisions. - Versioned templates, localization, safe rendering, personalization boundaries, and immutable audit context. - Channel workers, provider adapters, timeouts, retries, dead letters, deduplication, and status webhooks. - In-app inbox state, ordering, read markers, multi-device behavior, and deletion or retention. - Observability, provider health, tenant isolation, abuse controls, cost, and realistic delivery semantics. ### Follow-up Questions 1. How would you prevent a timeout retry from sending two SMS messages? 2. What happens when quiet hours end and a user has hundreds of pending notifications? 3. How would you change providers without losing status history or violating opt-outs? 4. Which data should be frozen at intent time versus resolved immediately before delivery?