We explained how the service registry solution comes in handy when pinpointing the location details of microservices and their instances. In a monolithic application, finding and calling application components happen through one of the language-level methods. If application components are being run in different process spaces, then there are remote method invocations (RMIs), remote procedure calls (RPCs), distributed component object model (DCOM), and so on. In a traditional legacy IT environment, applications run at fixed and well-known locations. That is, the hosts and ports are fixed in order to be found and used. Applications, therefore, can easily call one another using any one of the standard communication and data transmission protocols. However, in the agile and adept microservices era, the number of microservices and their instances are changing frequently. Further on, in order to bring about much-desired optimization, microservices and their instances are being redeployed in other locations. Therefore, client microservices need to use an advanced service discovery mechanism to get to know the latest status of microservice instances. For simplification, there are two main service discovery patterns—client-side discovery and server-side discovery.

For client-side discovery, the client will get the location of a service instance from service registry, as the registries has the information of latest locations of all the services. The client knows the address of the Service Registry. The client then uses a load balancing algorithm to select the optimal service instances and makes a request.

For server-side discovery, the Client makes a request to the API Gateway. The API Gateway then queries the Service Registry to get the network location of the desired microservices. Based on that location information, the API gateway makes an attempt to connect and leverage the ability to serve microservices.

The following diagram illustrates the differences between client- and server-side service discovery: