What is the difference between client-side and server-side service discovery?

The difference is who does the registry lookup and load balancing.

Client-side discovery

The caller queries the registry directly, gets the list of healthy instances, and picks one to call.

• Pros: caller controls load balancing (round-robin, latency-aware, sticky), no extra hop.
• Cons: every service in every language needs a discovery client library; caller must handle registry outages.
• Examples: Netflix Eureka, HashiCorp Consul (when used via SDK).

service-A → Registry: "give me healthy service-B"
Registry  → service-A: [ip1, ip2, ip3]
service-A → ip2 (picked by client)

Server-side discovery

The caller hits a fixed load-balancer DNS name. The LB does the lookup and forwards the request.

• Pros: caller is dumb — any language works; LB handles health checks and balancing.
• Cons: one extra network hop (in practice <0.5 ms on Kubernetes).
• Examples: Kubernetes Services + kube-proxy, AWS ELB / NLB, Azure Load Balancer.

service-A → http://service-b (Service DNS) → LB → ip2 (picked by LB)

Which wins in 2026?

Server-side via Kubernetes Services. It ships with every cloud Kubernetes (AKS, EKS, GKE), integrates with health probes, and removes the need for per-language discovery libraries. Client-side is mostly legacy at this point.