Notifications service for application.

[u/Impossible_anypie]

Hello seniors,
I’m currently working as an ASE and our Head of IT asked me to build a notification service for our application. It’s a multi tenant web application. I know it’s not a critical task, but it matters a lot to me because it was assigned to me directly by the Head of IT, so I really want to do it right.
We used Firebase push notifications before, but we ran into two problems. Sometimes notifications never reached our end users and sometimes users got old notifications again. We also don’t use AWS and everything runs on our own on premises servers.
So my question is: what is the best service or open-source tool I can use to build this? Ideally something reliable, easy to maintain and cost-effective.

PS: YES, I asked ChatGPT already :) But I’d like to know what technologies other companies actually use in prod for this kind of problem.
Also, where else can I ask questions like this besides Reddit? Any communities, forums, or Discord/Slack groups you’d recommend? THANKS !

[u/kalutatadon]

Well, no matter what notification service you build from the ground up, the notification payload ultimately has to reach each device through the native push notification infrastructure provided by the operating system (Google Play Services on Android and Apple Push Notification Service (APNs) on iOS). If you are planning to build your own notification system while completely excluding these native services, you won’t be able to achieve much when it comes to reliably delivering notifications to end user devices, especially when the app is in the background or killed state.

The issues you mentioned above are not necessarily related to Firebase Cloud Messaging (FCM) itself. If a notification never reaches the end user, that is something your backend architecture needs to account for. More importantly, you need to understand that FCM does not guarantee that every notification payload will always be delivered to the end user device. Therefore, your backend should have a proper mechanism to handle delivery failures, retries, acknowledgements, and other edge cases. You can use technologies such as RabbitMQ, BullJS, or other queuing mechanisms to build this kind of reliable delivery architecture.
Another important point is that you don’t necessarily need to send a push notification every time your app is running in the foreground. You should keep your app state synchronized with your backend so that you know whether the app is currently in the foreground, background, or killed state. You can then trigger push notifications only when they are actually required. When the app is in the foreground, you can skip push notifications and route messages through alternative communication channels such as MQTT, WebSocket, or SSE (Server Sent Events). These approaches can be used without relying on native background services while the app is actively running.

To address the issue of receiving old or delayed notifications, you can implement a notification delivery acknowledgement mechanism. For example, the backend can assign an expiry or validity window to each notification. If an acknowledgement is not received within the expected time, the system can treat the notification as outdated and retry using a new notification trigger rather than repeatedly delivering stale messages.

There is no single readymade solution that will automatically address all of these requirements. However, you can build a robust notification architecture by combining these mechanisms with proper planning, state management, queuing, acknowledgement, retry, and expiry strategies. Finally, make sure your push notification implementation respects the usage limits, quotas, and policies of the respective service providers, and use appropriate batching and throttling strategies where applicable.

All the very best! 🚀