Why HTTP is bad for Micro Service

First of all, You need to understand.

The Hypertext Transfer Protocol (HTTP) is the foundation of the World Wide Web, and is used to load web pages using hypertext links. HTTP is an Application layer protocol designed to transfer information between networked devices and runs on top of other layers of the network protocol stack. A typical flow over HTTP involves a client machine making a request to a server, which then sends a response message.

An HTTP request is made by a client, to a named host, which is located on a server. The aim of the request is to access a resource on the server.

To make the request, the client uses components of a URL (Uniform Resource Locator), which includes the information needed to access the resource. The components of a URL explains URLs.

A correctly composed HTTP request contains the following elements:
01) A request line.
02) A series of HTTP headers, or header fields.
03) A message body, if needed.

Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs. These services are owned by small, self-contained teams.

Microservices architectures make applications easier to scale and faster to develop, enabling innovation and accelerating time-to-market for new features.

Benefits of Microservices:
a) Agility
b) Flexible Scaling
c) Easy Deployment
d) Technological Freedom
e) Reusable Code
f) Resilience

Let’s consider that. A new connection service is available. You can go and apply for a new connection if you want to have more functions available when a connection is required. The connection service must verify the user’s fixed line connection, TV connection, and inclusion or exclusion from a blacklist of individuals who have been blocked by other providers. The user can obtain a fresh connection if all goes according to plan. The user presently has access to the support, connection, packages, accounts, and billing tables.

Use the connection table to start a new connection. Use the support table to create a support ticket. You can identify your packages with the use of package tables.

The system’s own organization offers additional services in a variety of ways. Check the user’s details to see if they have a fixed line or TV connection by using the new connection service with the user ID. If all of the information is accurate, data should be recorded in tables.

Another problem is that databases could be spread across several departments. The majority of tables will probably insert the recode properly, but not all tables will.

The request can be sent all at once if the HTTP protocol has been used for all verification services. Requests are made, other services are validated, and then we wait for a response from their system if the 4G connection service is down and another provider’s user verification service has slowed down significantly. Everyone will have to wait until they hear back before using other services to validate if 100 questions are sent all at once. A cascade failure is what’s known as the aforementioned problem. The entire process was a failure because no one knew the 4G connection’s state because it was offline, making it impossible to activate service from a different provider.

To determine if a transaction was successful or failed, the user interface must wait until a batch operation is run. The system backup process is necessary because of this problem. This illustration demonstrates how inadequate HTTP is for handling the backend of microservices. The same server is receiving various requests from Services A and B. A sent 400 questions to B, and A was awaiting replies. In response to an HTTP request, responses are always sent and always arrive in the same order. HTTP is useless because it uses an asynchronous system despite being synchronous. As a result, using HTTP for microservice backends is not recommended.

A Kafka like message system offers the solution. All other verification services connect to Kafka, which serves as their central hub. They first accept Kafka’s request, search the databases, and then return with information on a different subject. The replies are being collected by a new connection service as it searches for Kafka messages. When a service is unavailable, Kafka stores the request and sends it whenever it is back online. As a result, replies can be given at any time and in any order, and they will still work asynchronously.

Related posts:

Discover who wrote your story.. “For His Purpose” is published by Nasha Raindrop.