Client-side and server-side service discovery differ in where the responsibility for looking up a service's location and choosing an instance actually lives.
Key Points: • In client-side discovery, the calling service queries the registry directly, gets back a list of available instances, and picks one itself, often with client-side load-balancing logic. • In server-side discovery, the client sends its request to a fixed address, such as a load balancer or API Gateway, which queries the registry and forwards the request on the client's behalf. • Client-side discovery avoids an extra network hop but requires every client to include discovery and load-balancing logic, coupling clients to the registry's 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 additional component. • Kubernetes' built-in Service abstraction is a common example of server-side discovery, resolving a stable service name to a healthy pod transparently.
Example: With client-side discovery using Eureka, an Order service queries Eureka for Payment instances and picks one itself; with server-side discovery in Kubernetes, the Order service just calls http://payment-service, and Kubernetes' internal networking picks a healthy pod without the Order service knowing anything about the registry.
Interview Tip: A concise interview answer is:
"Client-side discovery has the caller query the registry directly and choose an instance itself, which avoids an extra hop but couples every client to the discovery logic. Server-side discovery routes through a load balancer or gateway that does the lookup for the client, keeping clients simpler at the cost of one more network hop."