# Design a Notification System — System Design Interview Prep

Source: https://www.skillbyai.com/en/system-design-interview/c-notify

> Many channels, reliable delivery.

## Queues per channel and user preferences

Producers (orders, social, marketing) send notification requests to an API that checks **user preferences**, rate limits and templates, then enqueues messages per channel (push, SMS, email). Channel workers call third-party providers (APNs, FCM, SMS gateways, email services) with retries, backoff and **idempotency** to avoid duplicates, record delivery status, and move permanent failures to a dead-letter queue. Separate queues stop a slow email provider from delaying urgent push messages.

## Components (sketch)

A design sketch, not a running system.

```text
services -> notification API (auth, validation, preferences, rate limits, templates)
         -> queues: push | sms | email   (priority lanes for urgent messages)
         -> channel workers -> APNs / FCM / SMS gateway / email provider
         -> status store (sent, delivered, failed) + dead-letter queue
         -> analytics: open and click events
```

## Respect quiet hours and opt-outs

Preference checks are a legal and trust requirement, not an optional feature.

**Quiz:** Why use separate queues per channel?

- [ ] To guarantee exactly-once delivery
- [ ] To use less memory
- [ ] Because providers require it
- [x] So a slow or failing channel does not block others

*Answer:* So a slow or failing channel does not block others. Isolation between channels.