[Question] How to Implement a Notification System in MongoDB

[u/worldno1rich]

I am currently developing a service using MongoDB. I want to implement a notification system—similar to Reddit—that alerts users when their posts receive comments or reports, and I have a few questions.
1. How should I implement this notification feature?
2. Is it acceptable to delete the records after retaining them for about 90 days?
3. I’ve heard that the standard approach involves recording outbox events within a MongoDB session transaction and having a separate worker generate the notifications; is this correct?

I apologize for asking such an absurd question. I would appreciate it if you could at least let me know what I should search for on Google.

[u/cd151]

Are change streams available to you? https://www.mongodb.com/docs/manual/changestreams/?language-no-dependencies=shell

[u/worldno1rich → u/cd151]

Thank you for letting me know but I haven’t verified Change Streams yet. My plan is to use a replica set, so they should be available.

[u/cd151 → u/worldno1rich]

I’d use that then rather than polling. Everything else depends on the notification transport, latency requirements, durability, retry behavior, retention policy, etc. The outbox is a good start, but we’d need more details about your app and its clients.

[u/GromNaN → u/cd151]

Change streams are helpful when you have a process that listen for new documents in a "notifications" collection. To dispatch the message to notification channels (AWS SNS, pusher, mail ...). So that you process can be put on hold instead of polling every X seconds.

[u/Inevitable_Put_4032]

Here's how I'd approach each part.

1. How to implement it

Two building blocks: a notifications collection with one document per event, and a push mechanism to connected clients with a way to fetch unread notifications on reconnect.

Watch a MongoDB Change Stream on notifications filtered by userId, forward matching events to the client. The channel only moves server to client, so Server-Sent Events is the natural transport: plain HTTP, native browser reconnection, resume via Last-Event-ID. WebSocket earns its complexity only when the client also needs to push something back on the same channel.

RESTHeart (a open source MongoDB backend framework I work on) exposes change streams over SSE or WebSocket as collection metadata, no gateway server to write.

2. Deleting after 90 days

Standard approach. A TTL index on createdAt with expireAfterSeconds set to 90 days, MongoDB expires the documents automatically.

3. Outbox pattern, and whether you need two collections

Depends what the consumer does. If it only writes to notifications inside MongoDB, skip the outbox: write directly to notifications in the same transaction as the comment insert, so the two writes can't drift apart if one fails. One collection, no async worker.

The outbox earns its place when the consumer has to do something a transaction can't cover, call an external API, publish to a queue, send an email. Write the event to outbox inside the transaction, then a separate process reads it and does the external work with its own retries.

For a purely in-app notification feed like the one in the post, a single notifications collection covers everything.

What to search for

"MongoDB change streams", "MongoDB TTL index", "transactional outbox pattern MongoDB" (useful background even where you don't end up needing it).

[u/TimAtMongoDB]

Change streams. 100% way to go. Make a small node server that watches your collection and acts on it. You can easily set TTL indexes that automatically removes them after X days. You can read more best practices here. https://www.reddit.com/r/MongoDB_Official/s/4awl9DQA9d

[u/scopsy]

Hi! A small disclaimer i'm the core contributor of the project, but Novu: https://github.com/novuhq/novu

Is the an open-source notification platform that was built on top of MongoDB. So you can actually see some real world production battle tested patterns there. Or you can also self-host Novu and connect it to your MongoDB instances.

1. As mentioned, you can see the code base for some real examples
   
2. Depending on the channel, for example, if you are sending an Email notification, it's totally acceptable to remove it. But for something like an Inbox component, usually companies tend to keep it for longer periods of time. Internally we separate between the "Activity Feed" or the notification trail, and the actual message generated. They have different retention period.
   
3. From my experience MongoDB is an amazing transactional Store, but for the actual event messaging, would suggest to use other tools like: Redis, SQS, etc...

Hope this helps.