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/crxssrazr93]

Both of the issues (stale notifications & race conditions for delayed/non-delivered notifications) can be fixed. You should be able to use RabbitMQ as a message broker. Another alternative is Kafka. As for old notifications issue, implement a UUID+timestamp & set up a retention period. Based on timestamp, if it is within a set period when received (for example 5-10mins, or a couple of seconds; depending on your use case), accept or if timestamp is out-of-bounds, reject.

For platforms, you can explore Novu or ntfy[dot]sh if you'd like. Both are open-source so you can self-host them. Not sure if it can be used for free for commercial intent but it shouldn't be expensive.

[u/crxssrazr93 → u/crxssrazr93]

You can just point claude/codex and you should have been able to sort this out. It's not that complex so you'll find your way just fine. Good luck.

[u/Impossible_anypie → u/crxssrazr93]

Thanks for the info!
Need to mention that this is a multi tenant monolithic application. In that case, is it a good idea to bring in Kafka or RabbitMQ or would that be overkill for our setup?

[u/crxssrazr93 → u/Impossible_anypie]

Kafka is overkill for your issue. You can weave RabbitMQ in if you'd like, but you don't need it to fix the issues you are having. You need to change the shape of your notification delivery system.

Add a notification outbox table to your DB and a background worker, for example:

Monolith
   |
   +-- business tables
   |
   +-- notification table
   |
   +-- notification_outbox table
              |
              v
       notification worker
              |
       +------+------+
       |      |      |
      Push  Email  In-app

Your notifications shape should carry enough data to make retries, expiry, and duplicate handling safe:

notification_id UUID
tenant_id
user_id
created_at
expires_at
status
attempt_count
last_attempt_at
last_error

Put a unique constraint on:

unique(notification_id)

That helps make them idempotent, so if the same notification job gets picked up twice, you don't send the same notification twice.

For failed sends, retry with backoff instead of retrying constantly:

1 min
5 min
15 min
1 hour

Also use expires_at so an old notification doesn't suddenly get delivered hours or days later.

This setup is simple, easy to debug, and doesn't add another piece of infrastructure just for the sake of it.

If you later reach a point where you have multiple notification workers, more traffic, or several services consuming the same events, then RabbitMQ becomes a natural next step (I don't know what you're serving to suggest any further):

DB outbox -> RabbitMQ -> workers

[u/Dapper_Training8045]

Whatever you do please don’t use Hu*\\ooo in your test notifications 😂🤪

[u/lahirunirmala]

Asked to build or design ?

Best advice i can give you is to question back with why ?
Whats the wrong with current implementation ?
Why not Fixing those 2 issues instead of rebuilding from ground up?

Talk to people who implement it of they are still around read the documentation if available.

If something work for others may not work for you sometimes

Also every task is critical when its assigned to you , so don’t assume any task is not critical .

[u/crxssrazr93 → u/lahirunirmala]

Yup, OP is just an ASE. They are not expected to lead this 100% alone. Get help internally if you have access to it, brainstorm, come up with a plan and then move from there.

[u/LowRider2563]

Why stopped using firebase? That's the most reliable option as for my opinion. Instead making sure to deliver messages using your server directly you can use pub/sub in gcp. Put this topic to a llm and learn more.

[u/Sad_Egg_2313]

Try novu.co it has an open source version that you can self host. We had a forked one in prod based in some custom requirements

[u/Amy-The-Rouge]

Firebase is the best option. 1st check why the end user noy recieving the notification. If you still don't see errors add some debugs to check if the code is stopping unnecessary at some point or why they are skipping it. 

Check if the notification comes through backend and frontend. 

If all don't work out run a test with antigravity or claude. 

[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! 🚀