0% completed
Notification System: System Definition
On This Page
Step 1: System Definition
A password-reset email, a push saying an order has shipped, and a two-factor code by SMS are usually built by three different teams. In a well-run company, all three still go out through one shared service. Each team calls it with a user and a message, and the service decides whether to send it, on which channel, and how.
In this case study, we design that shared service. Sending alerts for one application is a small job. The difficulty comes from serving many applications at once, each with its own users, traffic spikes, and idea of what is urgent.
Step 1: System Definition
A notification system is a central service that delivers messages to users on behalf of many separate applications. Each application is a tenant: a social network, an online store, or a chat tool that calls the service to reach its own users. Amazon Simple Notification Service (SNS) and Firebase Cloud Messaging work this way.
One service can carry a friend's post, a shipped package, and a chat mention, as long as each tenant's users and data stay separate from every other tenant's. The diagram below shows the entities the system stores and how they relate.
- Tenant: an application that uses the service to reach its own users, with its own users and events.
- User: the person who receives a notification. Every user belongs to one tenant.
- Notification: a message about one event, for one user or many, such as "Your order #1234 has shipped".
- Channel: the path a notification takes to the user. The system supports four: in-app, push, email, and SMS.
- In-app notification: a badge or feed entry inside the application, which should appear immediately while the user is active.
- Push notification: a message delivered to a device through the platform's push service, Apple Push Notification service (APNs) for iOS or Firebase Cloud Messaging (FCM) for Android. It arrives even when the app is closed.
- User preferences: settings that let a user opt out of some types or channels, or set quiet hours with no notifications at night.
- Multi-tenancy: one system serving many applications on shared machines, while keeping each tenant's users and notifications separate.
Most of that list is about choice. Channels are the paths the system can use, and the user's preferences decide which ones it may use for each message. The service therefore never simply sends what a tenant asks for; it first checks what the user has agreed to receive.
Design Guru Guru
· 4 months ago
Are we solving problem of multi tenancy here? So are we saying that we designing the APN like system? Or Notification service inside a big tech like Meta? . If the later is true then where is the question of multi tenancy?
Can you please fix your HLD diagram?
dos
· 7 months ago
I highly recommend to put background-color: black for the SVG (HLD) picture. as there are no arrows visible with white background. Please could you fix this issue on all High Level Design Schemas.
Sagar Sundriyal
· 7 months ago
Sorry but your HLD design is at basic level only!
No failures system is handled !
- In your design one Kafka queue is bottleneck - How critical, default, low priority notification will work under huge notification(email) sales ?
- If user deleted app or unsubscribed - then system will keep on retry the request! Rather than blacklist.
P B
· 10 months ago
- Since "user_id" is the primary key in "users" table, assuming "user_id" isn't reused between tenants. If so, "tenant_id" is a redundant information in "scheduled_notifications" table since it can be looked up from "users" table based on "user_id" field in the "scheduled_notifications" table. (The same argument applies for "notifications" table and a few other tables). "template_id" can be used for this purpose as well.
- "scheduled_notifications" table only contains "template_id". It doesn't have the necessary information to construct the actual message based on the template.
- "user_preferences" table has "language_preference". But it's not utilized anywhere. Though we might have indicated it in the "Additional Features" section, it would be appropriate to omit this in the schema if
P B
· 10 months ago
such as a recipient identifier, message content or template, and at least one channel
One can argue that having "at least one channel" in the request is unnecessary. If no channel is present, the requirement could drive the notification to be sent to all the channels registered for the user.
Reading Progress
0%
On This Page
Step 1: System Definition