Architecture To Manage Push Notifications In Your Multi-Functional App

Table of Contents

Push Notifications are widely known for the higher open and interaction rate it brings in.

The concept behind push notifications is quite simple: they are messages sent to a user’s mobile device from an app they’ve downloaded. Their purpose is to add value and keep the user interested in the mobile app.

Messages in push notifications are usually short as they have a restricted character limit (as opposed to, for example, text messages). In fact, the shorter they are, the better their click-through rates. Moreover, if a user clicks on a push notifications, they’ll be redirected directly to the mobile app that sent the message, which makes them a quite convenient marketing strategy.

An essential tool to inform users about events that require their immediate attention.

Push Notifications Architecture

An app that provides multiple services sends out millions of push notification in a day. These apps need very strong technology solutions to provide this huge volume of notifications.

Here is how a multiservice booking app solution can have it all sorted, so the entrepreneurs can start their business without any hindrance.

Multiple Booking Flows

A multiservice booking app has multiple booking flows. Each flows requires to send flow specific push notifications.

This requires the system to be specific enough to send push notifications to single or multiple flows. (For instance, Push notifications for booking a courier delivery can not be sent to all the other flows.)
Notifications for delivery agents cannot be sent to the drivers.


These notifications also had to take care of individual users. One person can be using courier and food delivery while the other person might be using food and ride-booking.

So the push notifications had to be optimised based on the services and individual users.

Multiple Notification Providers

To provide push notifications on both Android and iOS requires multiple notification systems.

push notifications

FCM (Firebase Cloud Messaging)  can be used to provide a reliable and battery-efficient connection between your server and devices that allows you to deliver and receive messages and notifications on Android. 

And robust, secure, and highly efficient APNS (Apple Push Notification service) for iOS.

Unique API keys and tokens for different application IDs are provided by these notification providers. For example, the FCM API key would be different for Ride Booking as opposed to Courier Delivery Service.

Multiple services that want to send notifications

Leveraging micro-service architecture makes it easy and possible for any service to be able to send a notification, without worrying about the multiple devices and providers.

push notifications

Also Read – Push Notifications For Higher Conversion


Architecture For Push Notifications System

A good and competitive push notification system can help with managing notifications for multi-service providing apps. Such notification system can be built using the webserver, Token Store,  notification workers.

Here is the detailed explanation of how the notification system works.

Step 1

When the user logs into the app, the application(ServiceGenie, Gotasker and ServiceX in this case) makes a call to Token store which saves these requests on the database in terms of UserID, Push Token and Device Token.

Step 2

The web servers forward the requests to Job Queues that assigns these queues to notification workers. These notification workers send these requests to the respective notification systems for Android and iOS.

POST http://<base_url>/notification
user_id: <user_id>
application_id: <pushtoken>{
	"payload": {},
	"title": "Service provider accepted your job",
	"message": "Contact your service provider"

This way, the expiration of one queue will not hamper other queues.

Push notifications system architecture

With this architecture, the flow is as shown:

  1. Requests are routed to one of the MobileFirst Server instances. This then sends a push message to the provider.
  2. Here all MobileFirst Server instances are capable of sending push notifications. But for a specific request, just one server instances performs the operation.
  3. Enterprise back-end initiates calls to the load balancer.

The biggest advantage here is that all MobileFirst Server is used to send push notifications. Therefore you can further add servers if you need to increase the number of messages per second. But there is a disadvantage also, every push message is a transaction on the MobileFirst Server.

This overhead can be mitigated by sending few messages together or by inculcating the IBM MobileFirst Platform Foundation adapter procedure. This invokes the call the back-end for a batch of messages and not for a single message.

Key Takeaway

Push notifications are no longer merely a tool in your marketing arsenal but rather an absolute necessity that you must integrate within your mobile app marketing strategy. We’re well into the mobile era, and that means businesses need to capitalize on the global shift to mobile devices as marketing channels.

If you’re not already implementing push notifications on your mobile app, it’s time to jump on board. You can utilize them now and reap the benefits later.

Architecture-To-Manage_push notifications

Share :
Disclaimer: The Blog has been created with consideration and care. We strive to ensure that all information is as complete, correct, comprehensible, accurate and up-to-date as possible. Despite our continuing efforts, we cannot guarantee that the information made available is complete, correct, accurate or up-to-date.

Similar Posts

We hope you find the blog informative and useful

Do you want help with your fundraising, just book a call?
Rahul Sharma, Founder & CEO
Scroll to Top

Contact us