How Microservices Find Each Other: A Guide to Service Discovery

System Design Refresher :

1. 10 System design trade-offs

2. Rate Limiting Algorithms Explained with Code

3. System Design of Reddit/Quora

4. Stateful vs Stateless Architecture

5. Best Practices for Developing Microservices

6. 10 Problems of Distributed Systems

7. 20 System Design Concepts Every Developer Should Know - Part - I

8. How Shopify handles 16,000 Request per second

9. Software Architecture Pattern - Layered Architecture

10. How Enterprise Applications Exchange Data Using Messaging

11. Microservices Design Pattern - Event Sourcing Pattern

12. Improve API Performance 🚀

13. Distributed System Learning Roadmap

14. 15 Scaling Techniques in Distributed Systems

When writing code that calls a service via a REST API, your application needs to know where to find that service—specifically, its IP address and port. In traditional setups running on physical servers, these network locations are often static and can be stored in a configuration file that's updated occasionally.

However, in modern cloud-native microservices environments, things are far more dynamic . Service instances are frequently created and destroyed due to autoscaling, failures, or deployments, and their network locations are assigned dynamically. Because of this constant change, your client code can't rely on static configuration—it needs to use service discovery to locate available service instances in real-time.

As you’ve just seen, you can’t statically configure a client with the IP addresses of the services. Instead, an application must use a dynamic service discovery mechanism. Service discovery is conceptually quite simple: its key component is a service registry, which is a database of the network locations of an application’s service instances.

The service discovery mechanism updates the service registry when service instances start and stop. When a client invokes a service, the service discovery mechanism queries the service registry to obtain a list of available service instances and routes the request to one of them.

There are two main ways to implement service discovery:

• The services and their clients interact directly with the service registry.

• The deployment infrastructure handles service discovery.

Server side

Server-side communication with the microservice is performed by using a service proxy. The service proxy is either provided as part of the service registry, or as a separate service. When

a microservice needs to make a call, it calls the service proxy's well-known endpoint. The service proxy is responsible for getting the location of the microservice from the service registry and forwarding the request. The proxy takes the response and routes it back to the original microservice that made the request. In the example scenario, load balancing is handled completely on the server side.

Using server-side invocation provides these key advantages:

• Simple requests

  The request made by the microservice can be simple because it is calling a well-known endpoint.

• Easier testing

  Using a server proxy takes any load balancing or routing logic out of the microservice. This configuration allows you to test the full function of the service using a mocked proxy.

This approach has the following key disadvantage:

• Greater number of hops

  Adding in a call to the service proxy increases the number of network hops per request. As a result, the number of hops per request is generally higher than for client-side solutions. It is worth noting that the service proxy can hold cached information about the other microservices, so in many cases, the request would go through four hops: 1 → 4 → 5 → 6.

Client side

The request from one microservice to another can be made directly from the client side.

First, the location of one or several instances of a service is requested from the service registry.

Second, the request to the microservice is made on the client side. The location of the microservice is usually cached so that, in the future, a request can be made without returning to the service registry. If in the future the request fails, then the client can repeat the call to the service registry. It is best practice to have the cached microservice location on a timeout. This configuration means that if a new version of a service is deployed, the other microservices do not have to wait for an error from their cached instance before being informed about the new instance.

Compared to the service proxy approach, this approach requires fewer network hops.

The above figure shows the required network hops. Again, this number of hops is for when the client does not have cached information about the services. In many cases, the request to the service registry is not required, making it just two hops: 3 → 4.

What you will get as a Paid Subscriber :

• A Cheat Sheet for Service Discovery Pattern.

• How to do Load Balancing in Service Discovery.

Test your knowledge - Questions and Answers.