Service Discovery

Service Discovery is how a consumer determines the network address of a service it needs to call. In modern systems, instances run on dynamically assigned hosts and ports, scale up and down, and move between nodes. Hard-coding http://10.0.4.7:8080 is brittle. Service discovery replaces fixed addresses with a logical name that resolves to a current, healthy instance.

How It Works

Discovery is built on a service registry that knows live instance locations. There are two main styles. In client-side discovery, the caller queries the registry, gets a list of instances, and chooses one using its own load-balancing logic. In server-side discovery, the caller sends the request to a router or load balancer at a stable address, and that component consults the registry and forwards the request. Kubernetes uses server-side discovery via a virtual service IP and DNS, hiding the registry behind ordinary name resolution.

The logical name is resolved at request time, so the set of reachable instances always reflects the current topology.

Many platforms blend the two styles: a sidecar proxy queries the registry on the client's behalf, giving client-side flexibility with server-side simplicity. DNS-based discovery is popular because it requires no special client library, though it caches aggressively and reacts slowly to change unless tuned. Whichever style is chosen, discovery must integrate with health checking so only healthy instances are ever returned.

When to Use It

Use service discovery whenever service addresses are not stable: container orchestration, autoscaling fleets, and multi-instance deployments. It is essentially mandatory for microservices on platforms like Kubernetes, ECS, or Nomad.

A fixed two-tier app at known DNS names may not need anything beyond a load balancer.

It is equally valuable in hybrid setups that span data centers and clouds, where addresses differ per environment and only a logical name can stay constant across them.

Trade-offs

Client-side discovery gives the caller full control over load balancing but couples every client to the registry and its API. Server-side discovery keeps clients simple but adds a network hop and another component to operate. Both depend on the registry being accurate; a lag between failure and deregistration means callers must still handle unreachable instances with retries and circuit breakers. A common pitfall is letting clients cache resolved addresses too long, which masks failovers; short, bounded caching with active health awareness keeps discovery responsive without hammering the registry on every call.

Related Patterns

Service Discovery depends on a Service Registry and on Self-Registration to populate it. An API Gateway often performs server-side discovery for inbound traffic. Combine with the Circuit Breaker and Retry patterns to tolerate stale entries. Health-check mechanisms feed both, ensuring only live instances are ever resolved.

Example

A recommendation service must call the catalog service. Rather than a fixed URL, it requests http://catalog. On Kubernetes, cluster DNS resolves catalog to a stable service IP; kube-proxy then balances the connection across the healthy pods currently backing that service. When the catalog deployment scales or a pod is rescheduled, the name keeps resolving correctly with no change to the recommendation service.