Messaging, Events and Email Systems · Notifications and Email at Scale
Designing a Notification System
Route events to email, SMS, push and in-app channels with preferences and rate limits.
A notification service receives requests (from events or APIs), applies user preferences and quiet hours, renders localized templates, deduplicates and rate-limits, then routes to per-channel workers (email, SMS, push, in-app) with retries and provider failover. Keep transactional and marketing traffic in separate priority queues, and track delivery status per channel.
order.shipped event
→ notification-service: load prefs(user, type='order_shipped') → channels [email, push]
→ dedupe key: order_shipped:ord_8812 (24h)
→ render templates (locale de-DE)
→ queues: email.transactional, push.transactional
→ workers → SES / FCM+APNs → status webhooks → deliveries table
Common pitfalls
- Notification spam from many events (batch into digests).
- Ignoring invalid device tokens.
- No opt-out controls per notification type.
Key points
- Preferences, templates, dedupe, rate limits
- Per-channel queues and workers
- Track delivery status
Further reading: Firebase Cloud Messaging
Practice questions
Why separate transactional and marketing notification queues?
Answer
A marketing blast of millions of messages must not delay time-critical messages like 2FA codes or order confirmations.
How do you avoid notification fatigue?
Answer
Respect preferences and quiet hours, deduplicate, rate-limit per user, and batch low-priority updates into digests.
Open in the app to mark lessons complete, take notes and track your progress.