Sale Ends In 15 : 54 : 35 Trending Now Data Structures Algorithms Foundational Courses Data Science

Design Notification Services | System Design

Read Discuss Courses

If we are building an e-commerce application or a booking system or

anything of that sort, we will always have a notification service that will be
used to notify your consumers. Let us now look at the requirements to build
a notification service.

Topics for Designing Notification Services

Requirements
Components
How does our system tackle if we want to send bulk notifications?
Scheduler
Pipelines
Batch Jobs
Use case for Notification Service

Requirements
There are some functional (FRs) and non-functional requirements (NFRs)
that this platform should support.

Functional Requirements:

Ability to Send Notifications: The first thing the system should be able
to do is send notifications.
Pluggable: It means we should be able to add the new features without
making a lot of changes to the system.
SaaS: It should be built as a SaaS product. This is because the main idea
is we should know who’s sending what number of notifications, and we
should be able to rate limit.

Example:
 Let’s just say it is being used by a company like Amazon, now there are
multiple business verticals. If all of them send us notifications, we will
get hundreds of notifications in a day. So that’s a very bad user
experience. The notification system should be able to put a rate limit
across all the users across all the platforms saying a particular user
should not get more than five notifications in a day.

AD

Complete Interview Preparation - Self Paced

Prioritization: Some messages have low priority while other messages are
of high priority. If we are sending a one-time password (OTP), then that’s a
very high-priority message. But if it’s a promotional message, it is okay if it’s
low priority, and if it gets delayed

Non-Functional Requirements:

High Availability: The notification service system platform should always

be available because it can be used by other companies, then downtime
would cost us a lot.
Many Clients: Moreover, it should be built in a way that it’s easy enough
to add more clients.

The diagram of architecture is as follows:

Components
The starting point of the whole system is a couple of clients i.e. Client 1,
Client 2. There are 2-3 kinds of requests that they can send us. But all of
those requests would come under a category called Notification service,
which is an interface that allows us to talk to the other teams in the
company, other companies, etc.

There are two kinds of requests mainly:

One is where they tell us the content we want to send to this particular
recipient
Another, for example, we have the user id of the recipient and send them
the required notification. We decide how we want to send it as an email,
or as an SMS or another way.

The first kind of model would be used by other companies where they
want to decide what they need to send as SMS or email. The second
kind of model would generally be used when we are building this to be
consumed within our own company. But normally as a SaaS product,
it’s good to have both interfaces.

The idea of the notification service is that it will take the request, put it into
Kafka, and respond to the client. We could make this transaction as a
synchronous flow but that will take a bit more time and that will keep the
client blocked. But if for a very critical scenario, we need it to be a
synchronous flow, we can make the whole process synchronous through API
calls.

Notification Validator and Prioritizer

There might be a lot of other validations, given certain kinds of events

that we want to do. All of those validations would happen in this
component which is called Notification Validator and Prioritizer. It
can also do some other tasks, validations are one part of it.

The main thing that it does is it decides the priority for a message. Based on
some attribute within the message. After deciding the priority, it puts the
event into a Kafka topic, specific for each priority. The idea is – we don’t
want any time lag in the high-priority messages, but at times, it would be
okay if there’s a spike in low-priority messages and hence it takes time.

Rate Limiter and Notification Handler & User Preferences

Here we are keeping the Rate Limiter before the Notification Handler
& User Preferences because the Notification Handler & User
Preferences is a slightly heavier component.

Rate Limiter does two kinds of rate limiting:

It checks the client who’s calling us, and if that client is allowed to call us
this many times.
It decides whether we are supposed to send these many notifications to
the user, so that the notification limit is not exceeded.

The next component is something called Notification Handler and User

Preferences. The user might prefer receiving emails over SMS or the user
may want to unsubscribe from all the promotional messages. So all of these
duties would be handled by this User Preference Service. It has two
components that it talks to:
 Preferences DB: which is our system’s single source of truth for all
user preferences. When we are developing it for our personal purpose,
this is primarily used.
User Service: The second entity that Notification Handler and User
Preferences will communicate with is a User Service

Note: We will have a complete mechanism that we may use to notify once
everything has been resolved

Email Handler

It is responsible for gathering and then transferring all email requests by

calling the email vendor, which will send out the real emails. The email
vendor could be a simple SMTP server that you have at our end.

In-App Handler

It handles all the in-app notifications that we want to send out or push
notifications. We can use a Firebase for Android and use Apple push
notification service for sending out such notifications on the iOS platform.

IVRS Handler

We can have an IVRS Handler. A classic example would be Amazon or

Flipkart. When we place a very high-value cash on-delivery (CoD) order,
they send us an IVRS call, to ensure that we have really made that
transaction and ask for our confirmation. So all of those things could be
handled by the IVRS Handler. This is a very rare scenario and it would
happen once in a while when compared to SMS or emails.

Notification Tracker

We always need to keep track of all notifications we have sent. In case

somebody later makes false claims there is some proof required, we need to
know what communication we have sent out. So for all of that, we have a
Notification Tracker which puts all the notifications that we have sent out on
its own Cassandra.

How does our system tackle if we want to send bulk

notifications?
Let’s say for all the users who have ordered a TV in the last 24 hours, we
have to send them a notification for installation service, these things are a
part of something called as bulk notification. So the very first requirement
for this would be a UI, which is represented as Bulk Notification UI (in the
architecture above), which will talk to something called as Bulk Notification
service, which takes a filter criteria. Filter criteria would be something like
finding all the users who have placed a milk order in the last three days and
sending them a notification.

Query Engine

On top of this data store, there’s something called as Query Engine. That
Query Engine basically takes a query, which is like an aggregator plus filter
kind of thing, and can be used to find out all the users who are in Bangalore,
or who have ordered some food item in the last few days. This Query Engine
is not only used by the Notification service, it could be used by a lot of
services.

Scheduler

A scheduler is a component that manages the timing and scheduling of

tasks or events. In the context of a notification service, the scheduler
determines when to send notifications based on user preferences, timing
settings, and priorities.

Pipelines

Pipelines are a series of steps or stages through which data or tasks flow. In
a notification service, pipelines can be used to process and transform
notifications before dispatching them to different channels. For example, a
pipeline might include steps to format the notification content, add
personalization, or apply language localization.
Batch Jobs

Batch jobs are recurring tasks or processes that are executed in batches,
typically with a predefined frequency or schedule. In a notification service,
batch jobs can be used to perform periodic tasks such as generating
aggregated reports, updating user preferences, or cleaning up old
notifications.

Use case for Notification Service

A common use case for a notification service is in an e-commerce platform.
The system can send various types of notifications to users, including order
confirmations, shipment updates, promotional offers, and abandoned cart
reminders. Users can manage their notification preferences, such as choosing
to receive notifications via email, SMS, or push notifications. The notification
service ensures timely delivery of notifications based on user preferences
and tracks user engagement metrics to improve the effectiveness of
notifications.

Whether you're preparing for your first job interview or aiming to upskill in
this ever-evolving tech landscape, GeeksforGeeks Courses are your key to
success. We provide top-quality content at affordable prices, all geared
towards accelerating your growth in a time-bound manner. Join the millions
we've already empowered, and we're here to do the same for you. Don't
miss out - check it out now!

Last Updated : 18 Sep, 2023 2

Similar Reads
Strangler Pattern in Micro- Google Cloud Platform -
services | System Design Designing an Issues
Notification System using…

What is System Design - Design a system that counts

Learn System Design the number of clicks on
YouTube videos | System…

Design Restaurant System Analysis | System

Management System | Design
System Design