This is the most important and commonly faced issue in the microservice pattern. It is practically impossible to create an application that performs at the same level throughout its life cycle. At some level, the performance of the application takes a hit in microservices, as your code is now distributed into different code components. There could be a scenario where to server one user call, your component has to call five different calls. So, any call can cause a delay, which results in the overall delay of the call. On the other hand, if one of the components is performing slow due to any reason and this component is the connecting point of multiple components, then it will delay the overall performance of the system:

Look at the preceding diagram. Suppose there is a web client that fires the request to get the profile data of a logged-in user. Think of this profile data like a Facebook profile. So, profile data is a mix of posts, reactions, images, friends list, and so on. To get this data in one call, we have used the API Gateway. We described API Gateways in Chapter 2, Defining Microservice Components. You learned where to minimize the traffic between the client and the server in a single request of the client. The server tried to reason with wall data to the client with the help of the API Gateway. The API Gateway, in turn, is responsible for making internal calls, getting all the data, and sending the final response to the client. During this procedure of gathering all the data, the API Gateway has to fire five different requests to five different microservices. Here, one service is overloaded or responding slowly due to hardware or something like that. This is why the overall performance is degraded. The turnaround time for client requests is increased due to this. So, one bad code can give us slow performance issue, and it is difficult to identify the exact component that is causing the issue.

Performance is not only about speed. It takes so many things into account, such as reliability, failover, and so on, which means we can't blame only the speed. Reliability and failover are also common issues in microservices. If your application is responding pretty quickly but isn't performing reliably, for example, sometimes it will give you result with 200 response code but sometimes it gives a 404 error, this is also a performance issue. So, this is speed at the cost of reliability and reliability at the cost of speed. User experience will be affected in any of the cases mentioned earlier. There should be a fine balance between speed and reliability.