Why HTTP based Microservices is Bad

Nikini Aloka
3 min readJul 21, 2022

--

In this Article, I discuss about what http based Microservices is bad.

HTTP is wrong choice for microservice. Are you agree with this idea?

Let see the example for understand it.

  • If someone providing mobile connection to the phone wants a system with unique identification of the user. when someone come to the system a new connection is creating.

But what is a microservices ?

  • microservices is isolate bounded context for each service. You need make sure doing one thing and doing it well.

Let’s consider that. A new connection service is available. When a connection is required, you can go and apply for a new connection if you’d want to have additional functions. The connection service must verify that the user has a fixed line connection, a TV connection, and whether or not they are on a blacklist of users who have been banned by other providers. If all goes well, the user can acquire a fresh connection. The user is currently connected to the support, connection, packages, accounts, and billing tables.

Connection table is used to active new connection. Support table is used to open some support ticket in case. Package tables are used to what is package you have

  • This system’s own organization offers a variety of other services. Using the user ID, access the new connection service, and verify the user’s details regarding their fixed line or TV connection. If every detail is accurate, then data should be stored in tables.
  • Then another problem has to face that the databases can be in different departments. Probably some table get successfully insert the recode, but some tables may not.

The request can be sent at once if the HTTP protocol has been used for all verification services. Requests are made, other services are verified, and then we wait for a response from another provider’s system if the 4G connection service is down and another provider’s user verification service has gotten very slow. If 100 queries come in at once, everyone must wait until they receive an answer after using other services to confirm.

This above problem called as Cascade Failure. There fore the entire transaction failed because cannot activate another provider service because don’t know the 4G connection result because it is offline. The UI have to wait and should have to run batch job to visit the transaction is happening or what is failed. Because of this problem the system has to have a backup process. This is a scenario that prove the HTTP is bad for microservices backend processed.

Multiple requests are being sent to the same server by services A and B. A sent 400 requests to B and was anticipating replies. When sending queries through HTTP, responses always arrive in the same sequence. It doesn’t work since HTTP is synchronous when an asynchronous system is being used. Therefore, using HTTP for microservice backends is not recommended.

A message framework like Kafka can be used as a remedy. All other verification services listen to Kafka, and new connection requests are forwarded to it. They accept the Kafka request, check it in the databases, and then reply with information about a different subject. A new connection service is listening for Kafka messages and gathering the responses. When a service is unavailable, Kafka saves the request and sends it once it is back online. The order and timing of responses are therefore irrelevant and operate in an asynchronous manner.

References

[1]K. Dinesh, Youtube.com, 2022. [Online]. Available: https://www.youtube.com/watch?v=bkpNvADPKZE&list=PLD-mYtebG3X9HaZ1T39-aF4ghEtWy9-v3&index=40. [Accessed: 19- Jul- 2022].

--

--