This topic describes the applicable scenarios of SOFAStack MSMQ to help you better determine how to use MSMQ in your business.
In the Internet finance scenario, its business involves a wide range of, such as payment transactions, fee interest calculation, merchant settlement, business marketing, membership points, risk verification, etc.; at the same time, it also involves many business peak moments, such as double 11, seckill, anniversary, etc. These activities bring great challenges to the processing performance of the micro-application in the distributed system.
As an important component in distributed systems, MSMQ can cope with these scenarios well.
The following example uses a payment transfer scenario to describe how a MSMQ implements the following features:
asynchronous decoupling
Data consistency of distributed transactions
Peak cutting and valley filling
asynchronous decoupling
Traditional processing method
The most common scenario is that after a payment transfer is successful, bills of both parties need to be generated, user entitlements need to be updated, and user notifications need to be sent. There are two traditional approaches:
Serial mode
The process is described as follows:
The user fills in the amount and other relevant information in the payment center to complete the transfer operation.
After the transfer is successful, a request is sent to Billing Center to generate bills for both parties.
After the bill is generated, a request is sent to the benefit center to update the user points.
After the credit is updated successfully, a request is sent to the user center to send a user notification.
Parallel mode
The process is described as follows:
The user fills in the amount and other relevant information in the payment center to complete the transfer operation.
After the transfer is successful, a request is sent to Billing Center, User Center, and Benefit Center to complete the corresponding operations.
Asynchronous decoupling mode
For users, after the transfer operation is successful, subsequent bills, rights, credits, etc. are not steps that need immediate attention, and can be guaranteed by the system.
The process is described as follows:
On the Transfer page, enter the amount and other relevant information to complete the transfer.
After the transfer is successful, a payment message is sent to the MSMQ. The MSMQ will immediately return a response to the payment center and the transfer is complete.
Downstream systems such as Billing Center, Rights Center, and User Center subscribe to MSMQ payment messages and complete subsequent workflow.
Asynchronous decoupling is the main feature of MSMQ. Its purpose is to reduce request response time and decoupling. The main applicable scenario is to put time-consuming operations that do not need to return results immediately (synchronously) into the MSMQ as messages. At the same time, due to the use of MSMQ, as long as the message format is guaranteed to be unchanged, the sender and receiver of the message do not need to contact each other, nor do they need to be affected by each other, that is, decoupling.
Data consistency of distributed transactions
In the payment process, the user entry is completed in the payment center, and the billing, equity, and notification systems are completed in other systems. The data between multiple systems needs to be consistent.
In this case, although the decoupling between systems is realized, the upstream system does not need to care about the business processing results of the downstream system; However, data consistency is not easy to handle, how to ensure the final consistency of the downstream system state and the payment system state. At this point, the transaction messages provided by the MSMQ need to be used to achieve state data consistency between systems. 
The process is described as follows:
The payment center sends a half transactional message to the MSMQ.
If the half transactional message is sent, enter 2.
If the half-transaction message fails to be sent, the payment center does not perform the transfer and the process ends. (The final payment center is consistent with the downstream system data)
The payment center starts the transfer process.
Transfer successful, enter 3.1.
Transfer failed, 3.2.
The payment center sends a half message status to the MSMQ.
3.1 Submit the half transaction message, generate a payment success message, and enter 4.
3.2 the half transaction message is rolled back, no payment success message is generated, and the process ends. (The final payment center is consistent with the downstream system data)
The downstream system receives a message that the MSMQ payment was successful.
The downstream system processes the related business logic. (The final payment center is consistent with the downstream system data)
For more information about distributed transactional messages, see Message types.
Peak cutting and valley filling
Traffic peak shaving is also a common scenario for MSMQ. It is widely used in flash sales or team buying activities.
Take the payment scenario as an example. In a spike or a team panic buying activity, the payment center may not be able to handle a large number of calls due to a large number of user requests, resulting in a sharp increase in traffic. After the payment center processes such a large amount of access traffic, the downstream application user center may not be able to handle a large number of calls, or even cause system crashes and other issues, resulting in missed notifications.
After the introduction of MSMQ, the user center, as a consumer, can consume messages according to its own application capabilities without being affected by large traffic.
