Service Discovery — Microservices Vocabulary

A service registry (e.g., Consul, Eureka, etcd) is the source of truth for service instance locations. Instances self-register on startup with their IP, port, health check URL, and metadata. Clients query the registry to discover available instances. In dynamic environments (containers, auto-scaling), IP addresses change constantly — the registry tracks this automatically.

Client-side discovery (Netflix Ribbon pattern): the caller queries the registry (e.g., Eureka), receives a list of healthy instances, applies a load-balancing algorithm (round-robin, least-connections), and calls the chosen instance directly. Advantage: the client controls routing logic. Disadvantage: each client must implement discovery and load-balancing code.

Server-side discovery (e.g., AWS ALB + ECS, Kubernetes kube-proxy): the client calls a well-known router endpoint. The router queries the service registry and forwards the request to a healthy instance. The client is decoupled from discovery complexity — it just calls one stable address. Kubernetes Services implement server-side discovery via virtual IP and iptables rules.

Health check endpoints (e.g., GET /health or /actuator/health) return 200 OK when the instance is ready to serve traffic and a non-200 code (or timeout) when it is not. The service registry polls this endpoint at a configured interval. If an instance fails health checks consecutively, it is marked unhealthy and removed from the pool — clients won't receive its address until it recovers.

Service registry (Consul, Eureka): stores where services are. Service mesh (Istio, Linkerd, Consul Connect): a network layer built from sidecar proxies that handles discovery, routing, mTLS encryption, retries, circuit breaking, and distributed tracing — all transparently. A service mesh often uses a service registry internally but adds rich traffic management on top.