Client-Side vs. Server-Side Discovery

One-Liner

The two main patterns for service discovery, differing in where the logic for finding service instances resides.

Client-Side Discovery: The client (e.g., an application calling another service) is responsible for querying the service registry to get a list of available service instances and then load balancing requests across them.
Server-Side Discovery: The client makes a request to a router or load balancer (which acts as a proxy), and this intermediary is responsible for querying the service registry and forwarding the request to an available service instance.

To offer different trade-offs in terms of complexity, performance, and flexibility in how services find and communicate with each other.

Client-Side: The client embeds a service discovery client library that interacts with the service registry.
Server-Side: An intermediary like a load balancer or API Gateway handles discovery. The client is unaware of the discovery process.

Client-Side Discovery

Pros: Fewer network hops (potentially lower latency), more flexible (client can implement custom load balancing or routing logic).
Cons: Requires a service discovery client in every language/framework, adds complexity to clients, clients need to be aware of the service registry.

Server-Side Discovery

Pros: Simpler for clients (they only call a well-known endpoint), centralizes discovery logic, easy to evolve without impacting clients.
Cons: Adds a hop to the request path (potentially higher latency), the intermediary becomes a potential bottleneck and single point of failure.

Client-Side: Netflix Eureka, Apache ZooKeeper, Consul (when using client libraries).
Server-Side: AWS ELB/ALB, Kubernetes Services, NGINX acting as a reverse proxy.

Using client-side discovery without a robust mechanism for client-side caching and health checking of the registry.