Web Notification System Design Problems

A notification is sent to a website. If a user sends an insite email to another user, then a message reminder number will be displayed on the navigation bar at the top of the website to prompt you for a new message. The above is just a simple example. There may be multiple types of reminders in the actual project ,... A notification is sent to a website. If a user sends an insite email to another user, then a message reminder number will be displayed on the navigation bar at the top of the website to prompt you for a new message.

The above is just a simple example. There may be multiple types of reminders in the actual project. For example, if a user gives you a message, the system prompts "x new messages" or "y new replies.

I plan to put all types of message reminders in one table (notice) and Mark whether the user has processed this message reminder, on the front-end of the website, you can only count this table. For example, if user A sends A private message to user B, A New unread message reminder is inserted in the notice table, it is used to remind users that after user B has viewed the private message, it returns to this notice table and marks it as handled or deleted directly.

However, there is a problem in the case of large data volumes or high concurrency. When the user has checked the new private message, the user can mark it in the notice table, for various reasons, the corresponding "unread message reminder" has not been written into the system. In this case, a problem occurs. When the user requests whether there is a "unread message reminder", it is written into the system again, then the system prompts the user to have a "new message", but the user has already handled it, but the "unread message reminder" is delayed.

If you want to count new message reminders, separate them in various services (such as private messages and messages), merge them, and then notify users. In this case, how can it be called a "Message notification system? I always think this is unreasonable.

For the Message notification system, does my notice table have any meaning? How do you design it?

Reply content:

A notification is sent to a website. If a user sends an insite email to another user, then a message reminder number will be displayed on the navigation bar at the top of the website to prompt you for a new message.

The above is just a simple example. There may be multiple types of reminders in the actual project. For example, if a user gives you a message, the system prompts "x new messages" or "y new replies.

I plan to put all types of message reminders in one table (notice) and Mark whether the user has processed this message reminder, on the front-end of the website, you can only count this table. For example, if user A sends A private message to user B, A New unread message reminder is inserted in the notice table, it is used to remind users that after user B has viewed the private message, it returns to this notice table and marks it as handled or deleted directly.

However, there is a problem in the case of large data volumes or high concurrency. When the user has checked the new private message, the user can mark it in the notice table, for various reasons, the corresponding "unread message reminder" has not been written into the system. In this case, a problem occurs. When the user requests whether there is a "unread message reminder", it is written into the system again, then the system prompts the user to have a "new message", but the user has already handled it, but the "unread message reminder" is delayed.

If you want to count new message reminders, separate them in various services (such as private messages and messages), merge them, and then notify users. In this case, how can it be called a "Message notification system? I always think this is unreasonable.

For the Message notification system, does my notice table have any meaning? How do you design it?

The design of the message system requires a data table to record notifications, such as the Notice table. As for this notification, there may be many types, just like the private messages and messages you mentioned, these can be expressed by fields in the design. Here we will share the Notice data structure design in Worktile.

{    nid: { type: String, unique: true },    published: { type: Number, default: Date.now },    verb: { type: String },    template: { type: String },    is_read: { type: Number, index: true, default: 0 },    is_pending: { type: Number, index: true, default: 0 },    filter: {        ftype: { type: String }    },    sender: { type: Actor },    receiver : { type: String , index: true},    data: {        entity: { type: Entity },        source: { type: Entity },        target: { type: Entity }    }}

For detailed design, refer to a standard of activity.
As for the high message concurrency you mentioned, there is actually no problem. After you mark the unread message as read, you can switch to the page, this is the mark before reading the unread message that it should have been processed long ago. Unless the high concurrency of your system has reached the system paralysis level, you do not need to optimize it too much without encountering any bottlenecks. Even if you reach the bottleneck, there are solutions, you can put all unread messages in the memory or redis to improve performance.

The above is about the data structure. Generally, web messages are updated in real time. This means that when you have not refreshed the page, the number of unread messages is displayed immediately. The practice of a real-time message system depends on the language used by your server. Node. js + socket. io
It is easy to achieve. Our product Worktile is implemented using the erlang language.

It seems that the system has a bottleneck and a layer of message cache is required. The efficiency of reading and writing messages in the direct database is low, because the data is readable During writing, resulting in inconsistent data, the message exists in redis or memcache on the middle floor of the memory. If there is still write or read inconsistency, it should be expanded horizontally!

Related Articles:

Message notification mechanism in HTML 5

Implementation of the Redis Message notification system

Message notification plug-in based on HTML5 Notifications API