With the server-side service discovery pattern, the ability to resolve the network address of the services is not present inside the individual clients—rather, this logic is moved into the load balancer. Inside a server-side service discovery pattern, a request flow looks like the following diagram:

This diagram shows the following process:

1. The Client makes a request for an API endpoint
2. The Load Balancer intercepts the request and queries the Service Registry to resolve the network address for the appropriate service
3. The Load Balancer then sends the request to the appropriate network service to handle the request

The advantage of this pattern comes in the form of a reduction of code duplication by the removal of service discovery logic from the clients and better load balancing because the service registry is not taking up the load of the load-balancing algorithms.

Now that we know how service discovery happens inside a microservices architecture, let's focus our efforts on understanding another interesting concept inside microservices.

Imagine that you are building an application that is supposed to handle multiple devices and the functionality provided to every device differs based on certain aspects such as mobile devices will not have feature for allowing to send a direct message to other users. In this case, every device will require a different API endpoint that it can call to access its specific set of services. However, making the clients aware of every single API endpoint can become an issue during the maintenance phases of the application, or when some of the APIs change. To handle these kinds of scenarios, we need to have something that can act as an intermediate layer for our communication.

Fortunately, inside the microservices architecture, we have something to help us with this problem. Let's take a look at what we have at our disposal.