System Design Case Study 7 - Design A Notification System

Understand the requirements and establish design scope

1. Where are we using this: pop up? Email? SMS? -> all
2. 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.
3. How many notification are going to send at once?
4. Are users have group? Send by group or all users.
5. 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
6. What a re supported devices? IOS, android, laptop, desktop
7. What triggers the notifications -> schedule on server side or controlled by a client application.
8. 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....

Email

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

1. How to prevent data loss?

   We can't have data loss so we persist notification data in database

2. 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.

Updated Design

Wrap up