Compare client-side and server-side service discovery: who queries the registry, who performs load balancing, and what does the calling service need to know about in each pattern?

## The question that splits the two patterns Service discovery patterns split along one key question: which component is responsible for resolving 'a healthy instance of service X' into a concrete address - the calling service itself, or something sitting between the caller and callee? ## Client-side discovery Client-side discovery pushes that responsibility into the caller. The calling service embeds a discovery client - either a library linked into the process (classic examples: Netflix `Ribbon` paired with `Eureka`, or a hand-rolled client using Consul's HTTP API) - that periodically fetches or watches the registry for the current list of healthy instances of the target service. When a request needs to go out, the client applies a load-balancing algorithm locally (round robin, weighted round robin, least-connections, or something registry-aware like health-weighted selection) and calls the chosen instance directly, with no extra network hop. This pattern gives the caller precise control: - it can factor in its own view of latency; - it can retry a different instance on failure without another round trip through a shared load balancer; - it can make routing decisions (e.g. canary weighting, zone-aware routing to minimize cross-AZ traffic) that a generic LB might not support. The cost is **coupling**: every service that calls other services needs the discovery library, which means it has to exist in every language your organization uses, be kept in version lockstep, and its bugs/outages (e.g. a bad cache of stale instances) are now distributed across every caller rather than centralized in one place to fix. ## Server-side discovery Server-side discovery keeps the caller ignorant of the registry entirely. The caller sends its request to a fixed, well-known endpoint - a hardware or software load balancer, an API gateway, a sidecar proxy (`Envoy` in an Istio/service-mesh setup), or, in Kubernetes, a Service's stable `ClusterIP` - and that intermediary is the one that queries the registry (or, in Kubernetes' case, watches `Endpoints/EndpointSlices`) and forwards or proxies the request to a concrete healthy instance. The calling code doesn't need any discovery-aware logic at all; it just does a normal HTTP or TCP call to one address. This dramatically simplifies clients and makes the pattern **language-agnostic** - a Python client and a Java client behave identically because neither knows discovery is happening. The trade-off is an added network hop (caller to LB, LB to instance) which adds latency, and the LB/proxy tier itself becomes a piece of critical infrastructure that must be made highly available - if it goes down or falls behind on registry updates, everything behind it is unreachable even if the instances themselves are healthy. ## Two textbook examples, and a hybrid A useful way to see the split concretely: - **Netflix's original OSS stack (`Eureka` + `Ribbon` + `Zuul`)** is the textbook client-side example - services registered with Eureka, and Ribbon-equipped clients pulled the registry and load-balanced locally. - **Kubernetes' native model** is the textbook server-side example - Pods register implicitly by matching a Service's label selector, `kube-proxy` programs iptables/IPVS rules on every node so that traffic to a Service's ClusterIP gets load-balanced to a ready Pod, and the calling Pod just does a plain TCP/HTTP call, unaware that a Service resource, a controller, and a kernel-level NAT rule sit behind it. - **Service meshes (Istio, Linkerd)** are a hybrid: they keep the 'dumb client' ergonomics of server-side discovery from the app's point of view, but implement the smart routing/load-balancing that client-side discovery offers by running a sidecar proxy alongside every instance, so the intelligence is distributed per-hop rather than centralized in one shared LB tier or embedded as a library in app code. ## Choosing between them in practice Choosing between them in practice usually comes down to organizational and operational constraints rather than a technical ideal: - **polyglot shops** without the appetite to maintain a discovery client per language gravitate to server-side discovery or a mesh; - **teams with a single dominant runtime** and strong requirements for custom routing logic (e.g. sophisticated canary/AB splitting done in-process) may prefer client-side. Kubernetes-native shops usually just get server-side discovery for free and only reach for client-side patterns or a mesh when they need capabilities the built-in Service abstraction doesn't provide, like fine-grained traffic shifting or mutual TLS between services.