Service Discovery

In a microservices architecture, a single user request may traverse 5-20 services. Each service runs multiple instances across different machines, containers, or serverless functions, with IP addresses that change on every deployment, scaling event, or failure recovery. Service discovery solves the fundamental question: when Service A needs to call Service B, how does A find B's current network address? Hardcoding addresses is impossible when instances are ephemeral; DNS with long TTLs is too slow to reflect real-time changes; and manually updating configuration files does not scale.

There are two primary patterns. Client-side discovery means the calling service queries a service registry (e.g., Consul, Eureka, etcd) to get a list of healthy instances, then selects one using a load-balancing strategy (round-robin, least connections, consistent hashing). The client library handles registration, health checking, and address caching. Server-side discovery means the calling service sends requests to a load balancer or DNS endpoint that resolves to healthy instances. The caller does not know individual instance addresses. Kubernetes Services (backed by kube-proxy or Cilium) are the most common example -- a service name resolves to a virtual IP that is load-balanced to healthy pods.

Health checking is integral to service discovery. A registry must distinguish between healthy instances (can serve traffic), unhealthy instances (running but failing health checks), and dead instances (no longer running). Consul uses a combination of agent-level health checks (HTTP, TCP, TTL, script) and gossip-based failure detection. Kubernetes uses readiness probes (HTTP, TCP, exec) to add/remove pod IPs from the Endpoints list. Without health checking, a service registry becomes a liability -- directing traffic to unhealthy instances causes cascading failures.

Modern service meshes (Istio, Linkerd, Cilium) push service discovery into the infrastructure layer. Each service instance gets a sidecar proxy (Envoy) or eBPF program that intercepts all network traffic. The proxy receives endpoint updates from a control plane (via xDS API) and handles routing, load balancing, retries, and circuit breaking transparently. The application code simply calls a hostname; the mesh handles everything else. This eliminates the need for client-side discovery libraries in each language and provides a uniform traffic management layer across all services.

The order service needs to call the payment service. With service discovery, the order service calls 'payment-service:8080' (a logical name). In Kubernetes, CoreDNS resolves this to a ClusterIP (e.g., 10.96.0.15). kube-proxy routes traffic to one of the healthy payment pods (e.g., 10.244.1.5:8080, 10.244.2.8:8080). If a payment pod fails its readiness probe, Kubernetes removes its IP from the Endpoints list within seconds, and no traffic is routed to it. When a new pod starts and passes readiness, it is automatically added. The order service's code never changes.