Design a Notification System

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.

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.

Quick check: Why use separate queues per channel?

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