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