The idea that using MQ can help to decouple business systems has been overstated.
The idea is simple, if there is no MQ in the flow of business state, then other systems want to know that the state has changed, and the core process system needs to proactively notify.
For example, the state of the order in the e-commerce system has changed from creation to processing. The customer service system needs to know, the risk control system needs to know, and the user system also needs to know.
The notification is done by RPC, and the data required by the downstream system can be carried in this RPC, or it can be checked by the downstream system when requested.
When the downstream system is added, the code of the core business also needs to be modified. For example, a new integral system has been created. Now the order status flow integral system also needs to be known.
The core system needs to continuously increase the invocation relationship to meet the new business side requirements downstream. The borderline logic has nothing to do with the ordering system itself, but because the downstream needs to get the data, we need to call the downstream interface using RPC ourselves. It doesn’t make sense.
When an accident occurs in a downstream system, it’s easy to send the core system down with you:
In this case, the core system depends on the downstream system mainly because the core system mentions the downstream system, which is the same as the coupling within the single system.
The simplest way to solve this coupling is to use dependency reversal in the single-module case, and introduce message queues in the distributed case:
After the modification, each order flow simply sends the Domain Event to the message queue. The downstream system has computing requirements, so you can just subscribe to the relevant topic.
That’s the end of it. That’s the fairy tale. In the original diagram, the dependencies we have are bidirectional:
The core system depends on the downstream system because of the call relationship, and the downstream system depends on the core system because the downstream system uses the core system’s data.
Our use of MQ only unlocks the dependencies in a single direction, and the core system has no calls to the downstream system.
In this way, when the downstream system crashes, it is less likely to affect the stability of the core system.
Implicit dependencies cause accidents
However, it is impossible to remove the downstream system’s data dependence on the core system. If the core system changes the code that generates domain events, the downstream system will still fail. In many cases, the failure is a dead end:
Bigger Internet firms often refactor their core services while leaving their downstream services in the lurch.
The data dependency is not an explicit dependency on the core system, so for the core system, it is an implicit dependency on me from the outside.
Invisible dependence is terrible, and everyone will slowly and gradually ignore it until the day of the accident.
Core systems re-establish dependencies on downstream systems
Although the dream is well done, the core system often returns some real-time computing data to the user in the process of serving the user. Where does this data come from?
A lot of it comes from the downstream computing system, for example, my order flow system, which now has to do some special logic when the user credits reach a certain condition.
As the business grew, the dependencies we had initially lifted were built up again.
Ring dependence is back! The next two systems could be you hang me up again. Round and round, we’re back where we started.