medium general · part of Practice Questions · Senior SWE Roadmap
Requirements to clarify
- Functional: send notifications across multiple channels (push, email, SMS), triggered by events, possibly with user preferences/opt-outs.
- Non-functional: must not lose notifications, must not spam (dedup/rate-limit), must handle bursty demand (e.g., a breaking-news push to millions at once), third-party delivery providers can be slow/rate-limited themselves.
Core components
- Event ingestion: upstream services publish “notify user X about Y” events onto a message queue, decoupling notification sending from the triggering action (see Message Queues & Event-Driven Architecture).
- Notification service: consumes events, checks user preferences (which channels, opted in/out), applies dedup/rate-limiting rules, and routes to the appropriate channel-specific sender.
- Channel-specific senders: separate workers/queues per channel (push via APNs/FCM, email via an ESP, SMS via a provider) — isolates one channel’s slowness/failures from the others.
- Retry & backoff: failed sends go through exponential backoff retry, with a dead-letter queue for persistent failures.
Key tradeoffs
- At-least-once delivery (risk of duplicate notifications) is usually accepted over risking lost notifications — idempotency keys on the client side handle the rare duplicate.