Notification System diagram template
Fan out email, SMS and push notifications through a queue with per-channel workers.
About this design
Notification systems fail by being synchronous: a slow email provider should never block an order from completing. This template accepts requests from internal services through one notification API, validates them against user preferences, and writes a message onto a durable queue. Separate worker pools consume per channel, one each for email, SMS and mobile push, so each can scale and fail on its own and each can respect its provider's rate limits. Workers call out to external gateways such as Twilio, record the delivery result, and push failures into a retry path with backoff. A preferences store holds opt-outs and quiet hours, which is both a product feature and a legal requirement. Use the diagram to discuss deduplication keys, template rendering, priority lanes for password resets, and how you would show delivery status back to the sender without polling every provider.
Diagram as text
This is the source of the diagram, in the ArchBoard diagram DSL. Paste it into Tools, Diagram from text to rebuild or change it.
title "Notification system"
direction LR
service orders "Order service" -> service notify "Notification API"
service billing "Billing service" -> notify
notify -> db postgres "Preferences"
notify -> queue kafka "Notification queue"
notification-queue -> worker email "Email worker" -> external "Email provider"
notification-queue -> worker sms "SMS worker" -> external twilio "SMS gateway"
notification-queue -> worker push "Push worker" -> external "Push service"
