Notifications in digital products should never detract from the user experience. Their purpose should be to contribute to people’s understanding that helps them achieve their goals. A notification alerts users to relevant information like important news, updates, events, etc. It has become an essential part of our daily lives. In this post we’ll learn how to design a notification system.
Functional Requirements:
- Dispatch notifications
- Prioritize notifications
- Send notifications based on customers’ saved preferences
- Single/simple and bulk notification messages
- Analytics use cases for diverse notifications
Reporting of notification messages
Non-Functional Requirements:
- High performance
- Highly available
- Low latency
- Flexible
- Highly scalable
Different types of notifications
Providers who want to send notifications to users must construct POST requests and send them to the Apple Push Notification Service (APN). The following information must be included in your request:
- The JSON payload you want to send
- The device token for the user’s device
- Request header fields specify how to deliver the notification
- For token-based authentication, your provider server’s current authentication token
The APNs validate the POST request using your server’s certificate or the authentication token provided by your server. APNs identify the user’s device if validation is successful. This device then receives your JSON payload.
Android push notification:
A similar notification flow is used by Android. Firebase Cloud Messaging (FCM) is frequently used to send push alerts to Android devices instead of APNs.
SMS messages:
Usually commonly used third party tools such as Twilio, Nexmo etc. are used for sending SMS messages.
E-mail:
Commercial email services such as Mailchimp, Sendgrid are some of the popular commercial email service providers which are used by various companies for their better delivery rate and analytics.
in order to send notification to user we first need to gather user information. On installing application user needs signup for the first time, API server will collect contact info and store it in database. Two tables can be created out of this information.
One user can have multiple devices so that push notification can be sent to all the user devices.
High Level Flow
Service 1…N: It can be a microservice or a cronjob that triggers notification sending events.
Notification System: It is used for sending and receiving notification. Can be treated as a layer between third-party systems and internal microservice/cron job. It will convert the notification payload for third party systems and then converts response from third party systems to microservice/cron job format.
Third Party Services: These services are responsible for delivering notifications to users. In order to expand the integration of third-party services, special consideration must be given. Extending a system by plugging in and unplugging third-party services easily is a good example of extensibility. Furthermore, it is crucial to consider the possibility that a third-party service will no longer be available in the future.
Problems with above proposed design:
- It is not scalable
- Has a single point of failure due to single notification server
- Performance will be a bottleneck as there’s a single server
How to improve it?
- Have more than one notification server and enable horizontal scaling.
- Introduce database and cache out of notification server.
- Introduce messaging queue to enable retries for failed notifications.
Notification Servers: APIs are provided for services to send notifications. For spam prevention, these APIs can only be accessed internally or by verified clients. Validate emails, phone numbers, etc. To render a notification, query the database or cache. Message queues should be used for parallel processing of notification data.
Cache: The cache contains information about the user, the device, and the notification template.
DB: Stores information about users, notifications, and settings.
Message queues: They eliminate inter-component dependency. When alerts are issued, message queues act as buffers. Because each notification type has its own message queue, a third-party service failure won’t affect any other notification types.
Workers: A group of servers that receive notice events from message queues and forward them to the appropriate third-party services make up the workers list.
End to End Steps:
1. To deliver notifications, an application uses notification servers’ APIs.
2. Notification servers retrieve cache or database data, including user information, device tokens, and notification settings.
3. The related queue receives a notification event for processing. iOS push notification events, for instance, is sent to the iOS PN list.
4. Workers access message queues for notification of occurrences.
5. Workers notify third-party services via alerts.
6. User devices receive notifications from third-party services.
Additional Improvements:
To improve the reliability of the system notifications can be saved inside notification log so that user always gets notification even if its delayed. Also, same user should not be sent same notification again and again. Worker will have access to this notification log and on receiving notification it will dedup using it.
While signing up users usually select to receive notifications or not this information can be saved inside User database and notification should be sent only to the users who agreed to receive it.
Analytics can be used to understand the user behavior and will help in taking data driven actions in future.