Search code examples
notificationsmessagingsystem-design

Notification System Design for Multi User Application

I have a requirement to design a notification system for multi-user(~1000 users) application, here are the high level requirements.

  1. System event gets triggered on specific operations.
  2. On event trigger, individual notification for all(or sometimes only for relevant) users gets generated and stored in database.
  3. While user logs in, all unread notifications for him will be pulled and displayed in ui.
  4. While user reads the notification, we capture the read status.
  5. A scheduler in background evicts all the stale notifications.

This seems like a very typical use case and straight forward to implement with the database.

But my doubt is, is there any way we can replace the Database with the Queue based messaging system? The reason I think this way is because, the use case I have seems like asynchronous in nature(like events, notifications and timely eviction of messages).

While I replace the Database with Queues, the first 2 points from above fits well, but on later part I have some doubts -

  1. In General, are queues flexible to store and query notifications based on user ids ?

  2. Consider this scenario - Notifications gets generated and stored in the queue, and the user is not logged in, what is the best way to handle consumer messages.

    a. Should the consumer constantly listen for the messages ?, If so should the messages be stored in application memory(does not seems to be good option) ?

    b. Or the consumers should be created for each users dynamically on user login? Is this a regular pattern ?

Any other recommended ways ?

Thanks

Solution

  • Your use-case is suited to a database, not a message queue. While conceptually similar to the use case, a message queue is intended for extremely short-duration storage (i.e. to buffer data moving between running processes). Since you have no control over when users log in, these notifications will potentially be stored for minutes, hours, maybe even weeks. You need a persistent storage mechanism.