Common Problems
Notification System
Understanding the Problem
🔔 What is a Notification System?
A notification system is an internal platform that other teams at a company use to send messages to users across channels like push, email, and SMS. Product services hand it a message and a recipient, and the platform takes care of actually delivering it.
This is a platform problem rather than a user-facing product, so our customers are other engineering teams inside the company. Notification systems are used to send messages to users, so internal clients are like the auth service that sends one-time passwords or the marketing team that blasts a promo to a million users at once.
Functional Requirements
This is the set I steer candidates toward when I ask this question. There are a lot of different ways this system can go so interviewers will try to get you to cover some of the key ones while they let you get creative with the rest.
Core Requirements
- Upstream services should be able to send a notification to a user via push, email, or SMS, either immediately or in the future.
- Upstream services should be able to send campaigns, the same message delivered to a whole segment of users, immediately or scheduled.
- Users should be able to set notification preferences (channel opt-outs and quiet hours).
Below the line (out of scope):
- Template management and rich content authoring.
- Delivery analytics dashboards (open rates, click-through tracking).
- In-app notification feeds and badge counts.
- Frequency capping across notification types.
Remember that you're not getting much credit (if any) for enumerating "below the line" requirements, so skip these if you're low on time.
Non-Functional Requirements
Before writing these down, we need a number to design against. This is a platform question, so how the system holds up under load is most of what we are being asked here.
Say we deliver 10M notifications a day. Spread evenly, that's about 100 per second which is honestly almost nothing.
But notifications don't spread evenly. If one of our clients schedules a campaign at 9am they expect most of it to be delivered at that time instead of dragged out through the day. Delivering 1M inside 5 minutes works out to over 3,000 per second, and that's a single campaign.
So we'll design for surges of 5,000 notifications per second or roughly 50x our sustained rate. This is big enough that warning lights should be going off in your head about how we handle it, that will focus our design.
The Set Up
Defining the Core Entities
API or System Interface
High-Level Design
1) Upstream services should be able to send a notification to a user, immediately or scheduled
2) Upstream services should be able to send campaigns to segments of users
3) Users should be able to set notification preferences
Potential Deep Dives
1) How do we guarantee an accepted notification is never dropped?
2) How do we deliver high priority notifications within 5 seconds, even during a campaign blast?
3) How do we prevent duplicate notifications on top of at-least-once delivery?
Final Design
Some additional deep dives you might consider
What is Expected at Each Level?
Mid-level
Senior
Staff+
Purchase Premium to Keep Reading
Unlock this article and so much more with Hello Interview Premium