Client Side vs Server Side Discovery Patterns

The two fundamental approaches to service discovery differ in who performs the routing decision. In client side discovery, the calling service directly queries the registry (or a local agent), receives a list of healthy endpoints, and selects which one to call. Netflix's architecture exemplifies this: services use Eureka for registry lookups and Ribbon client libraries to load balance across returned endpoints. The client makes the routing decision.

In server side discovery, clients send requests to a stable virtual endpoint like a load balancer or gateway. That intermediary consults the registry and routes to a backend. Kubernetes uses this model: you call a service IP, and kube proxy or an ingress controller routes to pod endpoints. Google's infrastructure uses VIPs backed by Maglev Layer 4 (L4) load balancers that distribute traffic across thousands of backends.

The tradeoff centers on where complexity lives. Client side discovery eliminates an extra network hop, saving 0.1 to 1 millisecond within a datacenter. It enables sophisticated locality aware routing where clients prefer same zone instances to reduce latency by 5 to 10 milliseconds and cut cross zone bandwidth costs by 80%. However, every service needs a discovery client library or sidecar, and bad client logic can cause system wide failures.

Server side discovery centralizes the routing logic, making it easier to evolve policies and add observability. But the load balancer tier becomes critical infrastructure. If it fails, all traffic stops. The extra hop adds latency: typically 0.1 to 1 millisecond intra datacenter, or several milliseconds cross region. At high throughput, the balancer can bottleneck; Google's Maglev design specifically addresses this by handling 10 million packets per second per machine.

💡 Key Takeaways

•Client side discovery saves 0.1 to 1 millisecond per request by eliminating the load balancer hop, critical for high throughput services making thousands of calls per second

•Server side discovery simplifies client logic but makes the load balancer tier critical infrastructure; failure takes down all traffic requiring high availability design

•Locality aware routing in client side patterns reduces cross zone traffic by 80% (Netflix keeps most traffic in zone), saving bandwidth costs and cutting latency by 5 to 10 milliseconds

•Client side requires consistent libraries across all services; a buggy client can cause system wide outages by misrouting or overloading backends

•Server side load balancers must handle extreme throughput; Google Maglev processes 10 million packets per second per machine to avoid becoming a bottleneck

📌 Examples

Netflix uses client side discovery with Eureka registry and Ribbon load balancing, clients cache endpoints and route with zone affinity to keep 90%+ traffic intra zone

Kubernetes implements server side discovery where service ClusterIPs are stable and kube proxy programs iptables or IPVS rules to route to changing pod endpoints

Google uses VIPs backed by Maglev L4 load balancers that perform consistent hashing to distribute packets across thousands of backends with sub millisecond failover

← Back to Service Discovery Overview