What is the Service Registry and Discovery pattern — client-side versus server-side discovery?

The Service Registry is a database of network locations (host + port) for all running service instances, kept up-to-date by registration (at startup) and deregistration (at shutdown or failure). Service Discovery is the mechanism by which a service caller looks up the current location of a dependency at runtime, replacing hardcoded hostnames with dynamic lookups.

Two styles of service discovery:

Client-side discovery — the calling service queries the registry directly, receives a list of healthy instances, and performs its own load balancing (round-robin, random, least-connections).

// Spring Cloud / Netflix Eureka client-side discovery
@LoadBalanced  // Ribbon intercepts and resolves via Eureka
RestTemplate restTemplate = new RestTemplate();

// Call by logical service name — Ribbon resolves to a real IP:port
String result = restTemplate.getForObject(
    "http://inventory-service/api/stock/SKU-99", String.class);

Server-side discovery — the caller sends the request to a load balancer (AWS ALB, HAProxy, Nginx, Kubernetes Service). The load balancer queries the registry and forwards to a healthy instance. The caller needs no registry SDK.

Kubernetes uses server-side discovery natively: a Service resource provides a stable DNS name and VIP; kube-proxy (or iptables/IPVS) routes traffic to healthy pods via Endpoints, which are kept current by the Endpoints controller watching pod readiness probes.