Requirements Analysis Case: Message Configuration Center

This article introduces a very common message push requirement, how to divide the boundary and how to design a technical solution when the system needs to push messages such as SMS, WeChat, and email.

1. Demand

A system generally distinguishes multiple business modules and splits them into different business systems. For example, the structure of a mall is as follows (too lazy to draw, I found one online):

There will be various services inside, and each service will have some message notification logic, for example:

• User Management:
  • If the user registers successfully, it is necessary to push an in-site message, welcoming the user and explaining some mall introductions;
  • User login: If it is judged that there is a risk in this login, such as a change from the last login IP or region, an email or text message should be sent to inform the user to change the password in time;
  • Pay attention to the WeChat official account: welcome to push the message of the WeChat official account to the user;
• Inventory management:
  • When the inventory is insufficient, send SMS and WeChat push to the merchant to remind to replenish the inventory;
• Payment Management:
  • Successful payment: Push the WeChat public account notification to the user successfully;
  • Payment failure: Push the WeChat public account and station letter notification to the user, and provide a link to facilitate the user to pay again;
  • Failure to pay after timeout: send text messages to users, push WeChat official account and station letter notifications, and remind users to pay in time;
• Risk management:
  • When suspicious operations occur, send text messages to users, push WeChat official account notifications, etc., to remind users of risky behaviors;
• Logistics Management:
  • Delivery notification: push the WeChat official account and station letter notification to remind users that the delivery has been made;

2. Boundary thinking

Unified message service construction

Based on these message notification requirements, in order to avoid repeated development of each module, it is easy to consider one point, which is to add a message module:

• External unified docking of various message services:
  • Different email services, such as NetEase Mail, Google Mail, Microsoft Mail, etc.;
  • WeChat push service, after the user follows, record the user's WeChat OpenID in order to push messages to the user;
  • To connect with the SMS gateway, according to the needs of the company, it may be necessary to connect with multiple SMS service providers for failover or price comparison;
  • In-site message notification: Provide a unified internal message notification capability within the company or the entire system;
  • Others: such as mobile phone push capabilities, Facebook, Twitter, Instagram, etc.
• Provide a unified interface internally for all modules to call and push messages
  • Usually an appId and appSecuret are provided for each module for interface authentication;
  • The unified interface input fields generally include:
    • appId: Used to identify which app wants to send a message
    • msgType: the type of message to be pushed, such as WeChat, SMS, site message, email
    • msgDetail: The message object to be pushed. According to the message type, different fields are defined, such as:
      • SMS only has template ID and placeholder replacement content
      • The station letter only has the title and content
      • The email has title, content, recipient, CC, attachment, whether it is an HTML email, etc.
    • sign: Signature information calculated according to the above fields + corresponding appSecuret, which can be realized by adding salt with md5, sha1 and other algorithms

Under normal circumstances, this message module will be developed uniformly at the company level, so that not only a single system does not need to reinvent the wheel, but even
all product lines of the entire company do not need to reinvent the wheel.
For the specific process, you can refer to an article on SMS login I wrote before, which draws a flow chart: https://youbl.blog.csdn.net/article/details/127124527

Concrete implementation of message service usage

In many systems I have seen, basically even if the module split is over in the previous step, the design of each module will continue.
Taking the payment service as an example, the message push process is briefly described as follows:

Experienced programmers know that such a design will have technical risks. When there is a problem with the message service interface, the payment service will be suspended and the MQ message middleware will be introduced Optimization, as shown in the figure below:

Note: This MQ message is different from the one mentioned above:

• MQ message: It is a message mechanism for the program to transfer events. Generally, it is only provided to the downstream program and will not be directly observed by the user;
• The news mentioned above: refers to short messages, emails, in-site messages, etc., which directly reach the user, and are messages that provide information for the user.

further problem discovery

After the system has been online for a period of time, the number of users will increase, and there will be user feedback, such as:

• I don't need the notification of payment failure, can it be turned off?
• Don’t push the successful payment news of a few yuan, only push the news if it can exceed 100 yuan;

If it's just a payment service, it's very simple. When calling the API on the payment service side, just make a judgment.
But when adding judgment, will it feel awkward? Some non-core logic will cause the code of the payment service to keep changing?

And other services will gradually add similar logic: message push switch, push threshold judgment, etc.
These similar logics cannot be reused because they are distributed in different service codes.

Is there a way to combine these codes? For example, is it OK to use the SDK?

Let's go back to the demand itself and think about it again. For example, does payment service and sending messages to users belong to the business scope of this payment service?
The successful payment pushes the message of successful payment to the user, which seems to be a payment business.
But:
the payment is successful, and the delivery needs to be delivered to the user. We know that this delivery does not belong to the business scope of the payment service, but the business of the logistics service. The
general implementation is that the logistics service monitors the payment success event and triggers the delivery event.
Then reasoning, Sending messages to users should not be the business of payment services.

So, is it the business scope of the message module to send messages to users? Obviously not, the message module, our previous definition, is to connect various message channels and reduce the coupling of various businesses to these channels. Whether or not to send messages, and how to send them, obviously should not belong to the business scope of this message module.

Can we deploy a separate module for message switching and message improvement threshold processing? Merge all the logic of "whether or not to send messages and how to send them" for all services here?
The answer is of course yes. Refer to our last request for restaurant queuing to issue vouchers . Coupon issuance after queuing timeout seems to be a queuing business, but it is actually a marketing business. It should not affect the normal logic of queuing services.
How to send messages should also not let the business pass Pay more attention, each business party, such as payment service, only cares about the action of payment, and throws an event at the corresponding node, and the job is over. Whether it is to be shipped or sent a message is an external business, and it should not Let the payment service take care of it.

3. Final design and implementation

Unified Messaging Service

Responsible for providing in-site message notification capabilities, and responsible for docking various message channels, such as WeChat, SMS, email, etc., to reduce the coupling of various businesses to these channels. For details, refer to the above text description.
The message service can not only provide an API, but also provide a globally unified message viewing interface, where you can view all message types, message channels, push or not, etc.; I found a picture of JD Cloud’s
message center for reference:

Unified message configuration center

Responsible for configuring whether each message is sent or not, and the threshold for sending each message (not shown in the figure below), configuration interface reference: The main workflow of the

message configuration center is as follows:

Note: This figure switches all business messages, all Concentrate on the message configuration center service, and because the message configuration center is a separate service, it has an independent database design, and the above payment service also uses consumers, but because the designer regards it as part of the payment service, generally The database of the payment service will be reused directly and coupled with the payment service.