Design patterns for sending Push Notifications

It could use several strategies to send Push Notifications to Mobile and Web clients. These strategies combine different integrations with FCM and APNS depending on the ecosystem of operating systems (iOS, Android) that need to be served. I summarize these patterns as follows:

HTTPS Triggers with FCM and APNS Approach
HTTPS Triggers with Independent FCM and APNS Approach
HTTPS Triggers with APNS Approach
HTTPS Triggers with FCM Approach
Event-Driven Approach

Each of these strategies and their related components is described in general below. I recommend the reader check my Push Notifications Handbook for more information.

HTTPS Triggers with FCM and APNS Approach

This pattern uses the FCM (Firebase Cloud Messaging) platform to distribute messages to iOS, Android, and Web clients.

Additionally, FCM communicates with APNS (Apple Push Notification Service) to guarantee the delivery of notifications to iOS clients in a secure manner and authorized by Apple.

Server notifications provide through microservices and API Gateway the integration for clients to register their devices to receive notifications, update tokens of one or more devices, generate requests to send notifications. Also, configure notifications and provide other functionalities that the solution requires at the Push Notifications level through, for example, a console.

The Server will also access the Database persistence mechanism that will store the tokens of the registered devices to be notified with the messages.

A database could also store particular settings for notification and required by Server.

HTTPS Triggers with Independent FCM and APNS Approach

This pattern uses the FCM platform to distribute messages to Android clients and uses the APNS platform to broadcast messages to iOS clients. Push Notifications distribution is designed using both platforms independently, unlike the previously exposed pattern.

In this pattern, the API Gateway, Server, and Database components fulfill the same functions described in the previous design, with the difference that in this strategy, Database will store both the tokens generated by FCM and the tokens generated by APNS.

HTTPS Triggers with APNS Approach

This pattern is appropriate when it is required to provide notifications only to iOS users. In this case, only APNS is used as a platform to manage and distribute the messages.

Remember that also through FCM can provide notifications to iOS clients. However, if you do not have short- and long-term plans to serve Android users, more successful use is to use APNS.

HTTPS Triggers with FCM Approach

This pattern is appropriate when it is required to provide notifications only to Android users. In this case, only FCM is used as a platform to manage and distribute the messages.

Event-Driven Approach

This pattern is a design with a Serverless approach. The execution actions come from HTTP triggers and triggers originating from databases, serverless functions (Cloud Functions or Lambdas), or programmed and automated batch processes.

In this pattern, Database Service is used to store the tokens and the required notification system settings. These services could be databases such as Firestore, DynamoDB, Realtime Database, RDS, and Cloud SQL.

As Microservice Serverless, you could use services available with FaaS such as Cloud Functions or Lambdas or serverless containers such as Cloud Run or Fargate.

Yair Carreno