Design Notification System

The Notification System alerts users with important information, including breaking news, product updates, events, offerings, etc. Notifications can be delivered through mobile push notifications, SMS messages, or emails.

Functional Requirements:

1. Different types of notifications (SMS, Email, Mobile Push)
2. Real-Time System (A slight delay is acceptable)
3. Subscription (User can opt-in/opt-out)

Non-Functional Requirements:

1. Highly Scalable (Sends out millions of notifications in a day.)
2. Supports multiple Devices (IOS, Android, Laptop/Desktop)
3. Reliable

Types of Notification:

1. SMS
2. Email
3. Mobile Push (IOS, Android)

Notification Component:

1. Provider: Build and Send notification to notification service.
2. Device Token: Unique Identifier used for sending push notifications.
3. Payload: JSON, contains notification payload.
4. Notification Service: Sends notifications to clients.
5. Client (Mobile Devices/Emails)

IOS Push Notification:

IOS Notification Flow

APNs: Apple Push Notification Service, a remote service Apple provides to propagate push notifications to IOS.

Android Push Notification:

FCM: Firebase Cloud Messaging sends push notifications to Android devices.

SMS Message:

Email:

Notification Flow:

Contact Gathering Flow:

Gather mobile device tokens, phone numbers, or email addresses. When users install apps or sign up for the first time, API servers collect user contact info and store it in the database.

DB Design:

High-Level Flow:

Design Deep Dive:

Reliability:

1. Prevent Data Loss: Persists notification data in the database and implements a retry mechanism.
2. Deliver notification exactly once: Due to the distributed nature could result in duplicate notifications. Use cache DB to check if the event(EventID) has been seen before or not.

Raw Design:

Notification System — Google Jamboard

Services:

1. Service 1 to N (Providers): Microservice, a cron job or a distributed system that triggers notification-sending events.
2. Notification Systems/Servers: Provide APIs to send notifications. Do validations to verify emails, phone numbers etc. Put notification data into the message Queue.
3. Cache: User Info, device info, and notification templates are cached.
4. DB: It stores data about users, notifications, settings, etc.
5. Message Queues: Buffers when high volumes of notifications are to be sent out. They remove dependencies between components.
6. Workers: List of servers that pull notification events from message queues and send them to the corresponding third-party services.
7. Third-Party Services: APNs, FCM, SMS, Emails etc.
8. Notification Log: To prevent data loss, persist notification data in a database.
9. Notification Template: Preformatted notification to create unique notifications by customizing parameters, styling, tracking links, etc.
10. Notification Setting: User-based setting to Opt In/Opt Out notification settings.
11. Rate Limiting: Limit the number of notifications a user can receive.
12. Retry Mechanism: When a third-party service fails to send a notification, the notification will be added to the message queue for retrying.
13. Analytics Service: Used for events tracking, such as open rate, click rate and engagements to understand customer behaviours.

High-Level Architecture:

ThankYou. Please do give suggestions.