Why HTTP based Microservices is a BAD idea

Let’s talk about that,
The main fundamental element of microservices is that they isolate bounded context to each service.

Let’s look at a new order of ABC company and see how the HTTP backend works.

image by Author

It is necessary to place an order first, then send a request to get the order stage. If we receive a response, we proceed to the process stage, and lastly, deliver the order.

Problem

As HTTP requests work on a sequence method, if one stage does not respond, the entire request is held until it is processed. If it receives 100 requests and the process stage is offline, the entire system will crash or be stuck, which is known as cascading failure. This is why HTTP-based Microservices are a bad idea.

Lets we take an another example,

image via author

When using HTTP as a backend, the first response will take 10ms to respond, the second will take 100ms to respond, and the third will take 30ms, but the second will take 100ms, so the third must stay until the second one is completed. This is the problem with using HTTP as a backend for microservices.

Lets go through a solution for that

Solution

We can use separate messaging framework like kafka

Taking the first example, when the order request comes, it pushes to kafka, then all the other sections (get order, process, and deliver) listen to kafka. If kafka sends them a request, they start their process and send back a response, but the offline stage was ok because kafka already got other responses by not waiting for the offline stage.

As soon as the process stage was online, he received the message from Kafka and processed it, so now all the responses have been completed, and the order can be processed.

As an example, in the HTTP way, the first 10 ms, the second 100 ms, and the third 30 ms, but if we use a messaging framework, it will work as follows
The first 10ms, the second 30ms, and the third 100ms…