CHAPTER 17

Design a Notification System

Multi-channel delivery with priorities, preferences, retries and provider failover

Source: PDF p. 54

Core PDF content
Functional requirementsNon-functional requirements and scale
- Send push (iOS/Android), SMS, email and in-app notifications - Templates, localisation, scheduling - Respect user preferences, opt-outs, quiet hours - Delivery tracking and analytics- Critical messages (OTP) delivered within seconds; bulk can lag - At-least-once with dedupe; never spam the same user twice - 100 M notifications/day (~1,200/s avg, bursts 50x for campaigns) - Resilient to third-party provider outages
Figure 38. Notification pipeline: one service enforces policy; per-channel queues and workers isolate failures of third-party providers. · PDF p. 54
QuantityEstimateDesign implication
Throughput100 M/day = ~1,200/s average; a campaign to 20 M users in 10 min = ~33,000/sQueues absorb bursts; scale workers on lag
PriorityOTP/security vs transactional vs marketingSeparate topics or priority lanes so bulk never delays OTP
Provider limitsFCM/APNs/SMS gateways throttle per senderPer-provider rate limiter and batching

Review questions for this chapter have not been written and reviewed yet. The chapter text above is the full source content.

Try it

References

System Design & AI System Design: The Complete Guide — 2026 Edition, p. 54; figures 38.

Tip: use ← and → keys to move between chapters.