Push Notification System Design Tutorial

Push notifications are a vital marketing tool for anybody with a mobile app.

It’s the finest way to communicate with your users, sending urgent messages to their mobile phones.

A mobile app can send a user a push notification, which is a brief pop-up message that appears on their smartphone even when the app isn’t open.

These alerts can include reminders, updates, discounts, and more.

They are created to catch users’ eyes. Title, message, picture, and URL are all possible components of a push notification. Emojis, logos, and other things can also be a part of them.

Operating systems like Apple OS and Google Android have diverse interfaces for push notifications.

Push notifications can be used to promote engagement, boost app usage, affect conversions, and so much more.

The options are genuinely limitless.

Push notifications for mobile devices, also known as push notifications for mobile devices, can supplement your usage of channels like email, SMS, and online push notifications with a number of special advantages.

You will receive a quick description of the notification service in this post and information on its objective, high-level design, special features, and more.

Objective

To develop a notification service that can efficiently distribute product-to-user messages across a variety of channels

Requirements:

• Sending API: Publish an authorized endpoint so that any backend and microservice can start delivering notifications.
• Compatible Channels: Support delivering alerts to any channel that publishes an API, such as email, text message, and push.
• The user’s preferences: Allow users to select their user preferences for each channel and notification.
• Limits for downstream service compliance: Avoid having your email or SMS service throttled or stopped.
• Scalable: Permit (theoretically) infinite horizontal scaling.

High-level Architecture

Let’s say your code is supposed to notify someone:

• The POST /send endpoint is invoked by your code. For each available channel, the request includes the userId of the recipient, the notification’s type, and its contents.
• The OAuth2 Client Credentials Flow is used by the /send end-point to authenticate the request.
• The user’s notification choices are then requested from the database. The preferences show whether or not the user is subscribed to a certain channel and notification.
• From the database, it will read user characteristics like email addresses and phone numbers.
• This endpoint will create a message object that includes user characteristics, channels, and channel-specific content. It won’t include deactivated channels, though. The message is then delivered to a fan out service.
• Incoming messages are disseminated to job queues via the fanout service. Filtering is in place, though, to disregard job queues for channels that aren’t specified in the message.
• Each channel has a processor and a work queue. The processor takes the task and then asks for the appropriate service, such as a transactional email or SMS service.

Major Architecture elements

POST/sent

You may very well have noticed that only the userId and neither the email address nor phone number are included in the request to this end-point. This enables the notification services to remain anonymous to your users.

To ensure scalability, the end-point is placed behind a load balancer.

Your typical user-facing authentication does not provide protection for the endpoint. 

You must utilize a distinct authentication method known as the OAuth2 Client Credential Flow used for server-to-server communication since the service that submits the request is the software itself.

Your application will provide notifications in many different places. You can utilize the send function almost anywhere, such as from a new codebase or your build workflow, by implementing it as an end-point behind a load-balancer, which guarantees that it is independently scalable.

PUT/user preferences

Use a key/value pair or NoSQL database that is extremely scalable. Format the records as follows: KEY: sample user id:sample notification id, VALUE: [“email”, “state: true,” “SMS”, “state: false,” channel: “email”, “email”, state: true”] ‍

If “false” values are present in the records, the transmit end-point will exclude the corresponding channel from the message delivered to the fanout. If there isn’t a record for a channel, the user hasn’t expressly indicated their preferences. You must consent to default in this scenario.

The user can modify the data in the user preferences database using your UI and a regular end-point that is secured by your standard authentication procedures.

Users will become irritated and be compelled to designate your alerts as spam or silence them if you don’t provide them the option to alter their notification preferences. Your user experience will be further harmed as a result, and email or SMS delivery services could suspend your account.

Fan Out

Fanout copies a message and distributes it to different locations. They are affordable and very scalable. Use SNS in AWS. Use Pub/Sub in Azure and topics and subscriptions in Google Cloud Platform.

To prevent sending pointless messages to excluded channel job queues, you can configure filtering between the fanout and work queues. For instance, in AWS SNS, you can specify that the email job queue should only get the fanout message if it has the “email” value in the “channels” field.

Even if you could create code to send the identical message to the required job queues, fanout is more efficient and requires less coding. Fanout also offers the convenience of adding and removing queues, allowing you to extend and reorganize your channels.

Job Processing

Messages are stored in queues pending processing by your job processors. They’re also affordable and very scalable. Job processors are pieces of code that process messages from the job queues. Depending on the volume of messages in the queue, they can scale.

The job processor should make an API call to the proper provider to deliver the notice in our scenario via a transactional email service.

The majority of email, SMS, and similar message delivery providers have tight requirements for the quantity and caliber of messages you send. Additionally, you want to examine these and set up suitable procedures thoroughly. Here is our advice on how to avoid being terminated from AWS SES.

You can define a maximum number of job processors to prevent exceeding the delivery services’ rate caps.

Further Improvements

You can have a glance at a bunch of these items.

• They need their own APIs, tables, etc. in order to have a scalable in-app notification service.
• Gathering and showing the open/click report
• Removing the contents of the notifications from the code and letting your product and design team modify the alerts visually instead without a code change
• Without changing any code, your team can use the dashboard to activate or disable notifications for certain channels.

Benefits of Push notification

• Boost User Interaction: Updates and fresh material will keep your users interested.
• Boost Communication Visibility: Ensure your messages are received immediately, even when people aren’t active. Send urgent notifications and provide users with a smooth experience.
• Maintain Retention: Use push notifications that are clearly visible to urge your users to return. You can increase user retention and reduce churn by pushing customers back onto your website and app.
• Enhance Conversions: By creating push campaigns around in-app awards, promotions, discounts, or other offerings, you can increase sales.
• Scale Your Enterprise: Your communication approach must scale as your audience expands. As your client base expands, push notifications are an effective method to stay in touch with them.
• Make the user experience connected (UX): By providing transactional alerts to consumers to keep them informed and provide a smooth cross-channel experience, you can reduce friction throughout the customer journey.

Conclusion

In conclusion, we gained knowledge about a scalable push notification service’s architecture. We also looked at the tools that are provided by all the main cloud service providers so that you can base your notifications on these.

Despite the fact that I tried my best to provide you with an overview of the push notification system architecture, there is a lot more going on behind the scenes.

I sincerely hope you will find this information useful and put it to good use.