Notification System Design

Objective:

Design enterprise level system architecture to support email, SMS, Chat and other public social app integrations using API:

• Email
• SMS/OTP
• Push notifications (Mobile and Web browser)
• Chat – Whatsapp/Telegram

It’s a generic feature of all kind of web and mobile applications, which is required for all modern distributed applications regardless of using any programming languages and technologies. You can customize based on your business use cases.

I have tried to simplify this design concept to fulfil common use case requirements with high availability, high perfromance and analytical services. It’s a very important medium of communication with customers/users thru their desktop/mobile devices. I would recommend to implement using microservice architecture and deploy ion Kubernetes containers to make it fully cloud native modern system. Let’s get started!

Functional Requirement:

• Send notifications
• Prioritize notifications
• Send notifications based on customer’s saved preferences
• Single/simple and bulk notification messages
• Analytics use cases for various notifications
• Reporting of notification messages

Non-functional requirements (NFR):

• High perfromance
• Highly available (HA)
• Low latency
• Extendable/Pluggable design to add more clients, adapters and vendors.
• Support Android/iOS mobile and desktop/laptop web browsers.
• API integration with all notification modules and external integrations wth clients and service providers/vendors.
• Scalable for higher load on-prem (VMware Tanzu) and on public cloud services like AWS, GCP, or Azure etc.

System Design Architecture:

Note: Please click on the image to see clear view!

These are the solution design considerations and components:

1. Notification clients:

These clients will request for single and bulk messages using API calls. These clients will send notification messages to simple and bulk notification services:

• Bulk Notification clients: These clients send bulk notification(s).
• Simple Notification clients: These clients send single notification(s).

2. Notification Services:

These services are entry services which will expose REST APIs to clients and interact with the clients.  They are responsible to build notification messages by consuming Template Service. These messages will be also validated using Validation Service. 

• Simple Notification Service: This service will expose APIs to integrate client with backend services. It’s a main service, which will handle simple notification request.
• Bulk Notification Service: This service will expose APIs to integrate client with backend services. It’s a main service, which will handle bulk notification request.

This service will also manage notification messages. It wills persist sent messages to databases and maintain activity log. Same message can be resent using APIs of these services. It will provide APIs to add/update/delete and view old and new messages. It will also provide web dashboard which should have filter option to filter messages based on different criteria like date range, priority, module user, user groups etc.

3. Template Service:

This service manages all ready-to use templates for OTP, SMS, Email,chat and other push notification messages. It also provides REST APIs to create, update, delete and manage templates. It will also provide an UI dashboard page to check and manage message templates from web console.

4. User Selection Service:

This service will provide services to choose target users and various application modules. There could be use cases to send bulk messages to specific group of users or different application modules. It could be also AD/IAM/eDirectory/user database/ user groups based on customer’s preferences. Internally, it will consume API services of User Profile Service APIs and check customers notification preferences.

5. User Profile Service:

This service will provide various features including managing users profile and their preferences . It will also provide feature to unsubscribe for notifications and also notification receiving frequency etc. Notification Service will be dependent on this service.

6. Common Notification Service

• Scheduling Service:

This service will provide APIs to schedule notifications like immediate or any given time. It could be any of these followings:

• Second
• Minute
• Hourly
• Daily
• Weekly
• Monthly
• Yearly
• Custom frequency etc.

There could be other services also, which can be auto-triggered messages based on the scheduled times.

• Validation Service:

This service solely responsible for validating notification messages against business rules and expected format. Bulk messages should be approved by authorized system admin only.

• Validation Service:

It will also prioritize notification based on high, medium and low priorities. OTP notification messages have higher priority with a time-bound expiry time, they will always be sent in higher priority. Common Outbound Handler will consume messages and process and send based on the same priorities from reading in three different queues high, medium and low. Another use case of bulk messages can be send using low priority during off hours. Application notifications during transactions could be sent to medium priority like email etc. Business will decide priority based on criticality of the notifications.

7. Event Priority Queues (Event Hub):

It will provide event hub service which will consume messages from notification services in high, medium and low topics. It sends processed and validated messages to Notification Handler Service which internally uses Notification Preferences Service to check users personal preferences.

It will have these three topics, which will be used to consume/send messages based on business priority:

• High
• Medium
• Low

8. Common Outbound Handler:

This service will consume notification messages from Event Hub by polling event priority queues based on their priority. High precedence will be given to “High” queue and so on so forth. Finally It will send notification messages to message specific adapter thru Event Hub.

This service will also fetch target user/applications from User Selection Service.

9. Notification DB

It will persist all notification messages with their delivery time, status etc. It will have a cluster of databases with a leader which will be used to perform all write operations and read will be on read replica/followers. It should be No-SQL database.

10. Outbound Event Hub:

It finally transmits message to various supported adapters. These adapters will be based on different devices (desktop/mobile) and notification types( sms/OTP/Email/Chat/Push notifications).

11. Notification Adapters:

These are adapters which will transform incoming messages from event hub (Kafka) and send to external vendors according to their supported format. These are a few adapters, we can add more based on use case requirements:

• OTP Adapter Service
• SMS Adapter Service
• Email Adapter Service
• In-App Notification Adapter Service
• WhatsApp Chat Notification Adapter Service
• Telegram Notification Adapter Service

12. Notification Vendors:

These are the external SAAS (on cloud/on-prem) vendors, which provide actual notification transmission using their infrastructure and technologies. They maybe paid enterprise services like AWS SNS, MailChimp etc.

• SMS Vendor Integration Service
• Email Vendor Integration Service
• App Push Notification Vendor Integration Service
• WhatsApp Vendor Integration Service
• Telegram Vendor Integration Service

13. Notification Analytical Service

This service will do all analytics and identify notification usage, trends and do a reporting on top of that. It will pull all final notifications messages from analytical database (Cassandra) and Notification databases for analytics and reporting purpose.

These are a few use cases:

• Total number of notifications per day/per sec.
• Which is highly used notification system.
• What’s average size and frequency of messages.
• Filter out messages based on their priorities and many more…

14. Notification Tracker

This service will continuously read Event hub queues and track all sent notifications. It captures metadata of the notifications like transmission time delivery status, communication channel, message type etc.

15. Cassandra Database Cluster

This database cluster will persist all notifications for analytics and reporting purpose. It’s based on write more and read less concept.

This will provide good performance and low latency for high number of notifications, because it internally manages high number of write operations and sync up with other database nodes and keep duplicate data/messages for high availability and reliability. Messages will be always available in case of any node get crashed.

Please share feedback and let me know if you have any suggestion to make this design better!

15. Inbound Notification Service

This service will expose API endpoint to external clients and applications to send inbound messages.

16. INBOUND event Hub

This topic will be used to queue and process all incoming notification messages from Inbound notification clients.

17. Inbound Handler

This will consume all incoming notification messages from INBOUND topic.

18. Inbound Notification Clients

These inbound notification messages will come from internal and external sources/applications.