How Service Discovery Works
IntermediateIn a microservices system, instances start, stop, scale, and move constantly, so their network addresses are always changing. Service discovery is how a service finds the current address of another without hard-coded IPs. Instances register themselves in a service registry, health checks remove dead ones, and callers look up healthy instances — either directly (client-side) or through a router (server-side). Kubernetes builds this in via DNS and its internal service abstraction.
Think of service discovery as a hotel front desk
Guests (service instances) check in and out constantly, and their room numbers change. Instead of memorising where everyone is, you ask the front desk (the registry), which always knows who is currently staying and in which room. If a guest checks out (an instance dies), the desk removes them. When you need to reach someone, the desk gives you their current room — you never rely on an old, stale number.
Step by Step
Key Concepts
Service Registry
The live database of available service instances and their addresses. Instances register on startup and deregister (or are health-checked out) on shutdown or failure.
Client-side Discovery
The caller queries the registry, receives the instance list, and chooses one itself (often load-balancing locally). Efficient, but every client needs discovery logic.
Server-side Discovery
The caller sends the request to a load balancer or router that performs the lookup and forwards it. Clients stay simple at the cost of an extra network hop.
Health Checks
Periodic probes that verify an instance is alive and ready. They keep the registry accurate so traffic is never routed to a dead or overloaded instance.
Key Facts
- Hard-coding IP addresses breaks the moment instances scale or move — service discovery exists precisely because addresses are ephemeral in cloud systems.
- In Kubernetes you rarely run a separate registry: the built-in Service plus internal DNS provides discovery and load balancing out of the box.
- Health checks are essential — without them the registry keeps handing out addresses of crashed instances, causing cascading failures.
Real-World Applications
Autoscaling microservices
As a service scales from 3 to 30 instances under load, new instances register automatically and callers immediately start using them — no config change or redeploy of the callers.
Zero-downtime deploys
During a rolling deploy, old instances deregister as new ones register and pass health checks, so traffic shifts smoothly to the new version without dropped requests.
Frequently Asked Questions
What is service discovery and why is it needed?
Service discovery is the mechanism by which one service finds the current network address of another. It is needed because in cloud and microservice systems, instances constantly start, stop, scale, and move, so their IPs are ephemeral. Instead of hard-coding addresses, services register in a registry and callers look up healthy instances dynamically.
What is the difference between client-side and server-side discovery?
In client-side discovery, the caller queries the service registry, gets the list of healthy instances, and picks one itself (usually load-balancing locally). In server-side discovery, the caller sends the request to a load balancer or router that does the lookup and forwards it. Client-side avoids an extra hop but requires discovery logic in every client; server-side keeps clients simple.
How does service discovery work in Kubernetes?
Kubernetes provides a Service object that gives a stable DNS name and virtual IP for a group of pods matching a label selector. Internal DNS resolves the service name, and kube-proxy load-balances requests across the healthy pods. This gives built-in service discovery and load balancing without running a separate registry like Consul or Eureka.
Why are health checks important in service discovery?
Health checks let the registry remove instances that have crashed or become unresponsive, so callers only receive addresses of instances that can actually serve traffic. Without them, the registry would continue handing out dead addresses, causing failed requests and potentially cascading failures across the system.