Service discovery lets services find each other's network locations dynamically, and it's implemented either as client-side discovery, where the caller queries the registry directly, or server-side discovery, where an intermediary handles the lookup.
Key Points: • In client-side discovery, the calling service queries a registry like Eureka or Consul directly, then load-balances between the returned instances itself, often with a library like Ribbon or Spring Cloud LoadBalancer. • In server-side discovery, the client sends a request to a fixed endpoint, such as an API Gateway or load balancer, which queries the registry and routes the request on the client's behalf. • Client-side discovery gives more control and avoids an extra network hop, but couples every client to the discovery library and registry protocol. • Server-side discovery keeps clients simple since they don't need to know about the registry at all, at the cost of routing through an extra hop. • Kubernetes effectively implements server-side discovery by default, resolving a Service name to a healthy pod IP via its internal DNS and kube-proxy.
Example: With Eureka and client-side discovery, an Order service queries Eureka for available Payment instances and picks one itself; with server-side discovery in Kubernetes, the Order service just calls http://payment-service and Kubernetes routes the request to a healthy pod transparently.
Interview Tip: A concise interview answer is:
"I'd use a registry like Eureka or Consul, or rely on Kubernetes' built-in discovery. Client-side discovery has the caller query the registry and choose an instance itself, which avoids an extra hop but couples clients to the discovery mechanism; server-side discovery routes through a gateway or load balancer, keeping clients simple at the cost of one more hop."