Service Discovery in Distributed Systems

In modern distributed systems, applications are split into multiple services running on different servers. When Service A needs to talk to Service B, it needs to know Service B's network location (IP address and port). But maintaining a static list of service locations becomes a nightmare when you have hundreds of services that frequently change locations.

Service Discovery solves this problem by providing a way for services to find each other automatically. Instead of hardcoding network locations, services register themselves with a service registry when they start up. When Service A needs to talk to Service B, it asks the registry for Service B's location.

Let's look at how service discovery works:

1. When a service starts, it registers itself with the registry, providing its name and network location.

2. The registry regularly checks if registered services are still alive through health checks.

3. When one service needs to call another, it queries the registry to get the target service's location.

4. If a service goes down, it's removed from the registry so other services don't try to call it.

There are two main approaches to service discovery:

Client-side Discovery means the client (Service A) directly queries the registry to find Service B. This gives more control to the client but requires each service to include service discovery logic.

Server-side Discovery uses a load balancer that sits between services. The client sends requests to the load balancer, which then queries the registry and forwards the request to an available instance. This simplifies the client code but adds another component to maintain.

Popular service discovery tools include:

• Netflix Eureka: Built for AWS, works well with Spring Boot

• Consul: Features strong consistency and DNS interface

• ZooKeeper: One of the oldest, used by many large companies