Service Discovery & Registration

In a monolithic architecture, services communicate by simply importing a function. In a microservices architecture, Service A communicates with Service B by making a network request to an IP address.

But there is a major problem: in modern cloud environments (especially with Kubernetes), IP addresses are totally ephemeral.

If Service B experiences high load, the autoscaler might spin up 5 new instances of Service B, all with random IP addresses. A few minutes later, it might kill 3 of them.

How does Service A know which IP addresses to send its requests to at any given millisecond? This is solved by Service Discovery.

How it Works

Service Discovery relies on a central registry—essentially a dynamic phonebook for your microservices.

Step 1: Service Registration

When a new instance of Service B boots up, the first thing it does is contact the Service Registry. It says, "Hello, I am an instance of Service B, and I am listening on IP 10.0.5.22, Port 8080." The Registry adds this to its list. The Registry also constantly pings the instances (health checks) to ensure they are still alive. If an instance crashes, the Registry removes it from the list.

Step 2: Service Discovery

There are two ways Service A can discover Service B.

Client-Side Discovery

When Service A wants to talk to Service B, it queries the Registry: "Give me the list of all healthy IP addresses for Service B." The Registry returns a list (e.g., [10.0.5.22, 10.0.5.25, 10.0.5.99]). Service A then runs its own internal load balancing algorithm (like Round Robin) to pick one IP and makes the HTTP request directly.

• Pros: Fewer network hops.
• Cons: You have to implement discovery and load-balancing logic inside every single client service, in every programming language you use.

Server-Side Discovery (API Gateway / Load Balancer)

Service A does not talk to the Registry. It simply sends its request to a central Load Balancer (or API Gateway) at a fixed, static address. The Load Balancer is the one that queries the Registry, finds the healthy instances, and forwards the request.

• Pros: The client code is incredibly simple. It just makes an HTTP request to http://service-b-lb/.
• Cons: Adds an extra network hop, which slightly increases latency. The Load Balancer can become a bottleneck.

Popular Tools

• Consul (HashiCorp): Highly popular for service mesh and discovery.
• Eureka (Netflix): Historically very popular in the Java/Spring ecosystem.
• Zookeeper (Apache): Often used for discovery and distributed configuration in older Big Data stacks (like Hadoop or Kafka).
• Kubernetes: In modern architectures, K8s handles service discovery natively via Services and CoreDNS, making external tools like Eureka largely obsolete for K8s deployments.