MQ (messaging queue) has been used a lot for the production environment in many companies. It plays an important role in designing the system. However, if you are asked the following questions during the interview, do you have answers?
- Why we need MQ?
- What kinds of problems might be caused by introducing MQ?
- How to mitigate those problems?
This article will try to find out those common but important questions.
Problems of the traditional approach
- Longer Latency
For some complex systems, one user request may depend on multiple third-party APIs. The user can only get a response when all third-party APIs respond.
The drawback of such a way is the longer response time, which brings users bad experiences like timeout especially during unstable network situations.
2. Tightly-coupled System
Microservices architecture is quite popular nowadays. For a large and complex system, we try to split them into multiple smaller components. We take placing an order as an example. When users place an order, initially the request will be handled by OrderService. Then the OrderService will call PaymentService, InventoryService, RewardPointService and ShippingService, respectively.
As you can see, these microservice components are tightly coupled. The OrderService becomes unavailable if any component failed.
3. Hard to Handke Peak Time
Sometimes there are some campaigns like flash sales in order to attract new users.
The system may work fine if the amount of requests is not large. However, what will happen if the requests suddenly increase? Even we can horizontally scale the components sometimes, but scaling databases is not easy like MySQL. The database will slightly become slower and down finally. The system becomes unstable and even unavailable during such peak times.
Why we need MQ?
- Asynchrony
For problem 1: Longer latency, we can try to make the system synchronized after introducing MQ. OrderServies does not have to wait for all third-party to respond, which will decrease the response time and improve user experiences.
2. Decouple the complex system
From problem 2, we can understand that if one system depends on more other systems then the system tends to be a tightly-coupled. After we introduce MQ, such a problem will be solved since the OrderService will only need to produce some events to alert other systems.
3. Decrease peek
Problem 3 could be solved by introducing MQ as well.
When OrderService receives a bunch of requests, it will create events and send those events to MQ. Since other systems like databases have their own limitation of RPS, they can adjust their speed to consume events from MQ.
