Ref Architecture: Push Notification

Push Notifications 

Push Notifications are meant for immediate action.

With today’s very normal micro-service architecture, sending push notifications to all or targeted devices possesses quite a bit of challenges if you want to –

• Target millions of push notification in a day.
• Supports multiple applications
• Allows user to use multiple devices and applications.

 With different types of devices, you need to support different notification systems. FCM for android, APNS for iOS, WNS etc. Each service will expect different set of keys or tokens.

With Micro-service architecture, each service wants to send notifications so it becomes very complex to maintain if every service needs to take care of all user applications and type of devices the user is logged into.

 With multiple applications and multiple devices, you need to manage notifications based on applications the user is using and different devices he is logged into.

For my Push Notification service, I would be following a reference architecture described in next section in order to support few million notifications per day.

Hope it sustains expected load and act as a reference architecture for new starters. Open for suggestions to improve it further.

Volumes can be further increased through high availability and running multiple instances as per need.

Architecture

Token Store

Whenever user logs in to Application, client sends registration token along with other metadata such as device type, userId, and application type to server.

Server stores above information in Token Store.

Services

Whenever any notification is to be triggered, different services or schedulers will send notification object over http to Notification Server.

Notification Server

Notification server exposes rest apis to send push notifications to client.

Registration tokens and other data is fetched from token store based on passed userId if we want to send targeted notifications.

Server schedules a job on one of the job queue based on current use case.

Job Queue

 We can use any queue management service like kafka, rabbitMQ as an exchange for our job queues.

The number of queues can be decided based on features, device type, or application types in order to have even load on all queues and clear segregation based on business logic.

The maximum number of queues can be dependent on number of cores available for efficient usage.

Notification Workers/Consumer

 The worker processes consume message from job queues and send out messages to respective providers based on device_type. If particular queue is loaded heavily (One feature/[device type]/application used more frequently than others) we can have multiple workers consuming messages from same queue.

Notification Providers

 Notification providers will send push notification to client devices . Providers will use different SDK and different mechanism to send notification based on the type of device they cater.