Client Side vs Server Side Discovery Patterns

Client Side Discovery
The client queries the service registry directly and selects an instance. The client maintains a local cache of available instances and implements load balancing logic. Advantages: no additional network hop, client can make intelligent routing decisions based on latency or locality. Disadvantages: discovery logic duplicated in every client, each language needs a discovery library, clients must handle registry failures.
Server Side Discovery
A load balancer or router sits between clients and the registry. Clients send requests to a known endpoint; the router queries the registry and forwards to an appropriate instance. Advantages: clients are simple (just make HTTP calls), discovery logic centralized, language agnostic. Disadvantages: additional network hop adds 1-3ms latency, router becomes a potential bottleneck and single point of failure.
Sidecar Pattern
A hybrid approach where a local proxy runs alongside each service instance. The sidecar handles discovery, load balancing, and routing. The application makes localhost calls; the sidecar routes to actual destinations. Advantages: combines client side intelligence with centralized management, language agnostic. Disadvantages: operational complexity of managing sidecars, resource overhead of running a proxy per instance.
⚠️ Key Trade-off: Client side offers lowest latency but requires library support per language. Server side simplifies clients but adds a network hop. Sidecar balances both but adds operational complexity.
Load Balancing Strategies
Both patterns need load balancing logic. Round robin: Distribute requests evenly across instances. Random: Simple, stateless selection. Least connections: Route to instance with fewest active requests. Weighted: Prefer instances with more capacity. Locality aware: Prefer instances in the same zone to minimize latency. The choice depends on workload characteristics.
Choosing a Pattern
Client side works well with homogeneous technology stacks where all services use the same language. Server side suits polyglot environments and when minimizing client complexity matters. Sidecar (service mesh) is common in container orchestration where sidecars deploy automatically.

💡 Key Takeaways

✓Client side: no extra hop, smart routing, but requires discovery library per language and duplicated logic across clients

✓Server side: simple clients, centralized logic, but adds 1-3ms latency and creates potential single point of failure

✓Sidecar: combines client intelligence with central management, suits container environments, but adds operational complexity

📌 Interview Tips

1Compare latency: client side has zero extra hops, server side adds 1-3ms, sidecar adds sub ms localhost call

2Match pattern to environment: client side for single language stacks, server side for polyglot, sidecar for Kubernetes

3List load balancing strategies: round robin, random, least connections, weighted, locality aware

← Back to Service Discovery Overview