Design interviews / Intermediate / 6 min
Design a notification system
Fan events out to push, SMS and email queues. Take the push provider down, fall back to SMS, and cap messages per user.
Start the simulation → Change the load, break a part, watch what happens. Free, no sign-up.
In short
- What it is
- A notification system turns events into messages on each user’s preferred channel: push, SMS or email, through outside providers.
- Why it matters
- Providers fail and slow down independently, and users stop trusting an app that spams or misses important messages.
- The trade-off
- Fallbacks and retries improve delivery but cost money (SMS) and risk duplicates, so messages need ids and per-user limits.
- Say it in an interview
- "Event → notification service (preferences, templates, per-user rate limit) → one queue per channel → workers calling FCM, an SMS gateway and an email provider, with retries."
Check yourself
Why give push, SMS and email separate queues?
Answer: A slow or broken provider then only delays its own channel. Isolation: if the push provider is down, email and SMS keep flowing instead of waiting behind stuck push messages.
What does a per-user cap protect against?
Answer: Spamming one user with many messages during a burst of events. A flash sale or a busy group chat can create many events for one person; the cap (or a digest) keeps it bearable.
Push is down and fallback to SMS is on. What is the cost?
Answer: SMS is slower and paid per message, so its queue and bill grow. Fallback keeps users informed, but SMS throughput is lower and every message costs money, so use it for important ones.