SysPad › Examples › Notification system

Notification system

A Notification Server fans out to one queue per channel (push/SMS/email) so a slow channel can’t back up the others - SNS for push, Twilio for SMS, SES for email - after checking each user’s opt-in settings.

Per-channel queue isolation with the preference/opt-in check that decides which channels a given notification actually fans out to.

Calling Services Users User (settings) Users Notification API API Gateway Notification Server Lambda Notification Settin… DynamoDB Delivery Log DynamoDB Push Queue SQS SMS Queue SQS Email Queue SQS Push Worker Lambda SMS Worker Lambda Email Worker Lambda Push (APNs/FCM) SNS AT LIMIT SMS Twilio AT LIMIT Email SES AT LIMIT

How it works

Notification Server
Reads the user’s opt-in settings, then drops one message onto each opted-in channel’s own queue. It never calls a provider directly, so a slow provider can’t stall it.
Notification Settings
Per-user opt-in / opt-out and quiet-hours. Read on every send to decide which channels fan out; written when a user changes their preferences.
Push Queue
One queue per channel is the whole point: if APNs/FCM slows down, push backs up here without touching SMS or email throughput.

Request flows

Send a notification

  1. Calling Services
  2. Notification API
  3. Notification Server
  4. Notification Settings
  5. Delivery Log
  6. Push Queue
  7. Push Worker
  8. Push (APNs/FCM)
  9. SMS Queue
  10. SMS Worker
  11. SMS
  12. Email Queue
  13. Email Worker
  14. Email

Update preferences

  1. User (settings)
  2. Notification API
  3. Notification Server
  4. Notification Settings

Other interview practice

Open this architecture in SysPad · All examples