0% completed
Notification System: System Definition
On This Page
Step 1: System Definition
Your phone buzzes while you are doing something else. The message reminds you that a meeting starts soon. You did not ask for it, and without it you would be late.
In this case study, we design the service that sends messages like that one. One application sending its own alerts is easy. The hard part is one service doing it for many applications at once. A social network, an online store, and a productivity tool should all be able to use the same service.
Step 1: System Definition
A notification system is one central service that delivers alerts and messages to users. It does that on behalf of many separate applications, and each of those applications is called a tenant. A tenant can be a social network, an online store, or a productivity tool. Amazon Simple Notification Service (SNS) and Firebase Cloud Messaging are systems like this. Many different apps use them to tell users about events, like a new message, a shipped order, or a calendar reminder.
You see these every day. Facebook tells you about a friend's post. Amazon tells you your package was delivered. Slack tells you someone mentioned you. One multi-tenant service handles all three cases for all three companies. It works because each tenant's data and users stay separate from every other tenant's.
Key entities and terms. Before we design anything, we name the things the system stores and the words we use for them. The diagram below shows how they fit together.
- Tenant: an application that uses the notification service to reach its own users. Each tenant has its own users and its own events.
- Notification: a message about one event, meant for one user or a set of users. "Alice liked your photo" and "Your order #1234 has shipped" are notifications.
- User: the person who receives a notification. Every user belongs to one tenant.
- Channel: the path a notification travels to reach the user. The common channels are in-app, push, email, and SMS. The system supports all four, so a tenant can reach each user the way that user prefers.
- In-app notification: a notification shown inside the application itself, like a badge or a feed. It should appear right away while the user is active.
- Push notification: a notification sent to a device by the phone's operating system service, like Apple Push Notification service or Firebase Cloud Messaging. It arrives even when the app is closed.
- User preferences: settings that let a user control what they receive. A user can opt out of some types, set quiet hours with no notifications at night, or mark some alerts as high priority.
- Multi-tenancy: one system serving many client applications while keeping them apart. Every tenant shares the same machines, but tenant A's notifications and users are kept separate from tenant B's.
Notice how much of that list is about choice. A channel is a path the system can use, and preferences decide which paths it may use.
Next: Step 2, where the requirements are defined.
Design Guru Guru
· 3 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
· 5 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
· 5 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
· 8 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
· 8 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