Service Discovery

What is service discovery?

Service discovery is the mechanism by which services locate each other’s current network addresses in an environment where those addresses constantly change. In a modern microservices or Kubernetes system, instances are ephemeral — autoscaling spins them up and down, deployments replace them, failures reschedule them — so hardcoding IP addresses is impossible. Service discovery maintains a live registry mapping logical service names (“payment-service”) to their actual, current instance locations, so a caller can find a healthy instance without knowing where it physically is.

How it works, and the two models

At the core is a service registry — a database of available service instances and their locations, kept current as instances register on startup and are removed (via health checks or deregistration) when they die. Callers query the registry to find a target. There are two architectural patterns. Client-side discovery: the calling service queries the registry directly and picks an instance (often load-balancing itself) — more efficient, but every client needs discovery logic. Server-side discovery: the caller hits a stable endpoint (a load balancer or router) that consults the registry and forwards the request — simpler clients, one more network hop. Health checking is essential to both: the registry must promptly drop unhealthy instances, or callers get routed to dead endpoints. Common implementations include Consul, etcd, and Eureka; Kubernetes has service discovery built in via its DNS and Service abstraction, which is why many teams get it “for free” without naming it — a Kubernetes Service name resolves to healthy pods automatically.

Where it fits in the modern stack

Service discovery is foundational plumbing for distributed systems and underpins higher-level infrastructure. Service meshes (Istio, Linkerd) build on it, adding traffic management, security, and observability on top of the basic “find the service” capability. API gateways and load balancers rely on it to know where to route. The reason it often feels invisible is that platforms like Kubernetes absorbed it into the runtime — but the moment you operate across clusters, mix VMs and containers, or run outside an orchestrator, you’re back to configuring discovery explicitly. The failure modes to respect: a stale registry (dead instances still listed → requests to nowhere) and registry availability (the registry itself becoming a single point of failure the whole system depends on).

What people get wrong

• Hardcoding addresses — in a dynamic environment instances move constantly; static IPs break on the first scale event or redeploy.
• Weak health checking: without prompt removal of dead instances, the registry routes traffic to endpoints that no longer exist.
• Registry as a single point of failure — the discovery system must itself be highly available, or its outage takes down inter-service calls.

Primary source: Kubernetes: Service (discovery)