Recently, we are implementing a message center module similar to Weibo and netease Cloud. The main function is to achieve the system in the likes, comments, @ and other messages do convergence. Today, I would like to share with you our design and implementation ideas.

First of all, we are currently a microservices architecture. Therefore, the design of message center in this article is also built on the basis of micro services, and the message center and other modules are independent of each other.

After analyzing the requirements, we can find the role of the message center as shown below (using the like message as an example) :

According to the requirements, we have the following two storage solutions.

Solution a:

Message table: message. The fields are as follows: User_id [user], sender_id [user], src_type [user], src_id [user], action [action], content_json [content], create_time [user]

Field Description:

Src_type and src_id are used to identify the source of the message.

The Action field is mainly used to store the type of the action, which is used to distinguish whether the message is a like, comment, or other type.

Content_json field is used to store all the content needed for the message display, including the content of the post, the post picture, the post creator and so on.

Scheme 2:

Message table: message. The fields are as follows:

User_id [user], sender_id [user], src_type [source], src_id [post ID], action [action], action_id [action ID], create_time [create time]

The action_ID field is used to find the content of the action. This field is not required when the action is like or comment. When the action is comment, you can use this field to enter the value in the message content table.

Message content table: message_content, fields are as follows:

Src_type, src_id, content, status, content status

One might wonder, why do YOU need the Message_content table? In fact, as we mentioned from the very beginning, we are the architecture of microservices. The message center is independent of other modules, so the message center does not and should not be evaluated by modules. It is a relatively independent module. So we need a content library to store the content in our system. The same is true of the content_JSON field in scenario 1, which requires storing so much content.

Let’s take a look at how the two schemes compare.

Solution a:

Advantages: 1. High scalability, no matter what kind of message can be thrown into the message table 2. The disadvantages of low coupling degree with other projects are as follows: 1. Complicated update actions; 2

Scheme 2: Advantages: 1. Simple updating action 2. Low coupling degree with other projects disadvantages: 1. Low scalability, the content stored in the Message_content table, format requirements

Based on actual service requirements, you are advised to use plan 2. In the actual scenario, deleting a post or deleting a comment and other operations need to affect the content status in the message. Scheme 2 has absolute advantage in updating content. If option 1 is used, updating the message content can be quite a headache.

If you have any questions or better suggestions, please feel free to discuss