System Design Case Study 7 - Design A Notification System
Understand the requirements and establish design scope
- Where are we using this: pop up? Email? SMS? -> all
- What is the message size?Does it text only or it contains images? -> 10 million mobile push notifications, 1 million SMS messages, and 5 million emails.
- How many notification are going to send at once?
- Are users have group? Send by group or all users.
- Is it real-time, by this I mean, notifications push with low latency( immediately ) - soft real time, if the system is experiencing a high work load, we could allow some delay
- What a re supported devices? IOS, android, laptop, desktop
- What triggers the notifications -> schedule on server side or controlled by a client application.
- Will use be able to opt-out -> yes
Propose high level design and get buy in
My first design
Different types of notifications
iOS push notification
Three components needed:
- Provider: build and send notifications requests to apple push notification service
- Device token: unique id
- Payload: JSON format
- APNS: remove service provided by Apple
- iOS devices: end client to receive the notifications
Android push notification
Android has a similar flow called FCM:firebase cloud messaging.
SMS
Third party service like twillio, Nextmo....
Although you could build you own service, many adopt a 3ed party service.
Sendgrid and Mailchimp are among the most popular email services, which offer a better delivery rate and data analytics.
Contact info gathering flow
Table schema:
Email and phone stored in user table, device token saved in device table, a user can have multiple devices and those can receive notifications
Notification sending/receiving flow
Service 1-N, a microservice, a cron job or a distributed system that triggers notifications
Notification system: starting from on server, provide APIs to service 1-N and build notification payloads.
Third party service: extensibility
iOS, android, SMS, email: clients
Problem:
- Single point of failure
- Scalability: hard to scale
- Performance Bottleneck
Improved design
Notification servers :(newly added)
- Carry out basic validation of email and numbers
- Query the db or cache for data needed
- Put data into a message queue
- Removes the dependencies between components.
- Different type notification has different queue to mitigate some service failure affection
Design deep dive
Reliability
-
How to prevent data loss?
We can't have data loss so we persist notification data in database
-
Will recipients receive a notification exactly once?
No. The distributed system could result in duplicate errors.
Deduce mechanism. When a notification event first arrives, we check if it is seen before by checking the event ID. If it is seen before, it is discarded. Otherwise, we will send out the notification.
Additional components and considerations
Notification template
maintaining a consistent format, reducing the margin error, and saving time.
Notification setting
Check if use is opt-in which notifications
user_id bigInt
channel varchar # push notification, email or SMS
opt_in boolean # opt-in to receive notification
Rate limiting
Retry
Securities
Only authenticated or verified clients are allowed to send push notifications using our APIs.
Monitor queue notifications
To avoid delay in the notification delivery, more workers are needed.
Even tracking
Analytics service implements events tracking to analyze customer behaviors. Integration between the notification system and the analytics service is usually required.