Why Messaging Queue?
Before we begin, if you haven’t read about design messaging queue yet, I recommend reading it on below link:
Let’s start with some questions:
Where should we prefer Messaging Queue ?
Why Messaging Queue is even required ?
Why can’t we have REST APIs everywhere ?
Let’s take an example:
Customer purchased a product on some e-commerce website. Product delivered to him within a day. He liked the product. He wanted to give the feedback about it. He went on the Feedback portal of the website and wrote an awesome review.
REST API Sync Call
When he clicked the submit button on the feedback portal, he did not receive the response immediately and a circle was showing on his screen resulted in a processing or a buffering state. Something like this:
Reason being:
We had a below design in the back-end, i.e., one rest api made a sync call to another api, that made a sync call to another api and so on
So it took around four to five seconds in responding back to the customer where we could have sent the response within milli-seconds.
This design is not good for customer point of view because:
- He doesn’t care what we are doing in the backend.
- He just wants a response that his feedback will be updated in 2–3 days.
- He doesn’t care if:
We are moving it to over CDN network for fast processing.
We are storing it in some blob storage.
We are storing it in S3 bucket.
We are validating whether he actually have placed an order.
If any of the Rest API fails in the process, we will throw the exception from that API. That API will further throw the exception to its caller API and so on. Customer will receive the response in an average of 4–5 sec something like-
“Please try again. Feedback hasn’t been updated successfully.”
Learning
REST API Sync call is not a preferable design for customer point of view. For both, success and failed cases, customer receives a response in 4–5 sec which is way higher in comparison to a few milli-seconds. Customer could be anyone — end customer or a client who is going to hit our APIs.
REST API Async Call
How can we improve this design ?
Asynchronous Call
Asynchronous calls do not block (or wait) for the API call to return from the server. Execution continues on in your program, and when the call returns from the server, a “callback” function is executed
When Customer clicked the submit button on the feedback portal, he received the response immediately within milli-seconds. Customer is happy. He received the response that — “Your feedback will be updated in 2–3 days.”
This is the best design for customer point of view. This is the minimal possible time we can send the response back to the customer. Time cannot be improved further. For Async call, we do not wait for the response instead we make a call and process starts in parallel and we don’t care about the response.
If any of the Rest APIs fails in the process, we will throw the exception from that API to its caller API. We can not throw the exception further if the caller API made an Async call. In this case, the message is lost.
Failed case of Async call is not a preferable design for customer point of view because-
We can not ask the customer — “Hey, we lost your feedback. Could you please share it again ?” No, we can not do that as we already have shared the response to the customer stated “your feedback will be updated in 2–3 days”.
Learning
REST APIs Async call is the best solution for the happy cases. For all the success cases, we can send the response to the customer in the best possible time.
But we cannot use the Async call because for failed cases, this is not a preferable design for customer point of view. Message lost is worst than delivering late. — “Better late than never”.
Messaging Queue
When customer clicked the submit button on the feedback portal, he received the response within milli-seconds. An API was called which worked as a producer of a messaging queue and pushed the message in the queue. Pushing the messaging in the queue and receiving the acknowledgement of successfully pushed might take few milli-seconds — 40 to 50 ms but still we can respond to the customer in milli-seconds. Instead of responding in say, 100 ms, we can now respond in 150 ms or so.
Failed Case
If any of the Rest APIs fails in the process, we will throw the exception to its caller API. We can build a retry logic now as per our use case. We can have the persistent layer on messaging queue.
This is one of the preferred design for this use case. Now Customer is happy for all the use cases, whether success or failed, and we are happy.
Back to the question
Where should we prefer Messaging Queue ?
Wherever client/customer doesn’t care about the process in the back-end and he wants a response ASAP for fast processing, we can use a Messaging Queue.
Why Messaging Queue is even required ?
Messaging queue is the preferable solution for some of the use cases. For an instance — where data persistence is required for short span of time to handle the failures. We should not use Databases everywhere for the data persistence when it is required for some time only, say to handle the failure cases or so. This is not recommended because database storage is costly and database calls are costly. When we say database calls, we mean the network bandwidth, latency in getting the response from the database.
Why can’t we have REST APIs everywhere ?
This is not preferable for every use case. This could result in message lost or in taking a lot of time to respond.
Few of the real-life examples where messaging queue can be used:
- Placing an order.
- Notifications.
- Sending feedback.
- Tweeting a post.
- Adjusting the size of an uploaded image.
- Converting an uploaded video to different formats.
Hope you all enjoyed reading it. Thanks for reading folks.!!!
