Case study: notification system

A notification system takes an event, such as "your order shipped" or "Alice commented", and delivers the right message to the right user on the right channel: push, email, SMS or in-app. It rarely needs clever data structures. It is a reliable pipeline with validation, preferences, fan-out to channels, retries and observability.

Almost every product grows one of these. Chat alerts, feed mentions, security codes and marketing campaigns often share infrastructure, with careful isolation so a Black Friday email blast can't delay login codes. Third-party providers are unreliable partners with their own rate limits. Your job is to be a good citizen upstream, and a stubborn, idempotent client downstream.

In an interview, look for the pipeline diagram, preference checks before enqueueing, per-channel queues, idempotency keys, provider rate limits and dead-letter queues. Strong answers also separate priority lanes and discuss digests against real-time sends.

Concepts in this section

Step	Concept	What it answers
1	Notification pipeline	What are the stages from event to provider?
2	Preferences and quiet hours	Should this message be sent, on which channel, and when?
3	Idempotency for notifications	How do retries avoid sending five codes?
4	Rate limits and provider quotas	How do you stay under each provider's limit?
5	Retries and provider failures	What happens to a message that keeps failing?
6	Priority lanes and broadcasts	How do security messages avoid waiting behind marketing?
7	Templates and localization	How are messages rendered safely in every language?

Common mistakes

Calling providers from the API request. Provider slowdowns then become slow requests for your users. Enqueue the work and return.
One queue for every channel. A throttled SMS provider then blocks push. Keep a queue per channel.
Sending before checking preferences. Check preferences, quiet hours and frequency caps before any work reaches a provider.
No idempotency. Producers, queues and providers all retry, so duplicates are a matter of time.
No alerts on the signals that matter. Alert first on OTP latency and dead-letter queue depth, then on marketing throughput.

Key takeaways

A notification system is a pipeline, not a single call to a provider.
Check preferences and quiet hours before enqueuing, and use digests for low-signal noise.
Idempotency keys and a delivery log beat hoping providers never duplicate.
Rate-limit per user and per provider, and isolate security messages from marketing.
Retries need backoff with jitter, capped attempts, dead-letter queues and token cleanup.