In a microservice-based application, services need to communicate with one another to carry out a business task. In a monolithic application, communication between services is very easy, because all services are typically part of the same application. However, in a distributed system, the services are not part of the same application. Instead, services run on separate, independent virtual machines or containers. These have well-known locations (hosts and ports), that change if the application is scaled up or down. This is where service discovery comes in.

In client-side discovery, a client service finds the location of other service instances by querying a Service Registry. The client is also responsible for managing load balancing requests across services. The Service Registry is a database for microservice instances. On the client side, we have to use an algorithm to select one of the available instances using a few parameters.

The following diagram illustrates the client-side service discovery pattern:

As you can see, the client service itself registers with the registry server. Other microservices also register with the same registry server. All instances of services are registered with the specific location on the registry server. The client service uses the service name with which it is registered, and is removed from the Service Registry when the instance terminates. The service instance's registration is typically refreshed periodically using a heartbeat mechanism.

This service discovery pattern has various advantages and disadvantages. The advantages are as follows:

This pattern is very simple and straightforward because there are no moving parts related to the distributed application, except the registry server

You can apply more intelligence on the client side to make load balancing decisions

The client-side discovery pattern also has the following disadvantages:

This approach couples the client code with the registry server code

You have to implement discovery logic for each service because the services may use different programming languages

Netflix OSS provides a client‑side discovery pattern called Netflix Eureka. Netflix Eureka is a Service Registry that provides a REST API to manage service‑instance registration and send queries to available instances. Netflix also provides another component called Netflix Ribbon, which is an IPC client that works with Eureka to load balance requests across available service instances. We will discuss Eureka in more depth later.

First, let's have a look at another approach: the server-side service discovery pattern.