Fundamentals · Beginner

Notification system

One API for push, email and SMS with preferences, per-channel queues and retries.

Every part, and why it is there

Product services

Orders, social, billing and so on. They say “tell user 42 their order shipped” and should not need to know about APNs tokens or email providers.

Notification API

Accepts a notification, checks the user’s preferences, renders the template, and drops one job per channel onto a queue. It returns quickly; delivery happens afterwards.

Preferences & device tokens

Which channels each user allows, quiet hours, and their phones’ push tokens. Respecting opt-outs here is a legal requirement for email and SMS, not just politeness.

Dedupe & frequency caps

Remembers recent notification ids and per-user counts, so a retried request is not sent twice and nobody gets 30 pushes an hour.

Push queue

One queue per channel, so a slow or failing email provider never delays push messages. Also absorbs spikes such as a marketing send to millions.

Email queue

Email is slower and has stricter provider rate limits, which is exactly why it gets its own queue and workers.

SMS queue

SMS costs money per message, so it is usually reserved for urgent items like login codes.

Push workers

Send to Apple or Google, retrying with backoff on errors and deleting tokens the provider says are no longer valid.

Email workers

Send through the email provider within its rate limit, retrying temporary failures and giving up on permanent ones like a bad address.

SMS workers

Send through the SMS provider. Fewer of them because volume is lower.

APNs / FCM

Apple and Google own the connection to the phone; you can only hand them the message. They are fast but do not guarantee delivery.

Email provider

An outside service (e.g. SES or SendGrid) that handles deliverability. A second provider is a common fallback.

SMS provider

An outside service such as Twilio that reaches carrier networks.

Delivery log

One row per attempt: sent, failed, opened. Lets support answer “did the user get it?” and powers retries and analytics. Write-heavy, so a wide-column store fits.

Asked in interviews at

  • airbnb
  • metropolis
  • coupang
  • amazon
  • microsoft
  • pinterest
  • reddit
  • fora

Concepts used here

  • Message queues: Let the fast part of your app reply now and the slow part catch up later. Nothing is lost in a rush, but any job may run twice, so make twice harmless.
  • Server-Sent Events: Build a live score page from one HTTP response that never ends: a few lines of plain text per event, a browser that reconnects by itself, and an id that lets it catch up on what it missed.
  • Token bucket: A rate limit with two knobs: how fast permits come back, and how many can pile up. Set both and a real app’s burst gets through while a flood does not.

Learn more

All system design examples