Spring Cloud LoadBalancer: Client-Side Load Balancing

What client-side load balancing means

• The routing decision happens inside the calling service, not on a central proxy
• No network hop through Nginx or ALB — the client picks the instance directly
• Spring Cloud LoadBalancer replaced Netflix Ribbon; ships with Spring Cloud natively

How the resolution flow works

• Call http://order-service/api/orders with a @LoadBalanced RestTemplate or WebClient
• Spring Cloud LoadBalancer reads the service name, resolves it to instances from the registry (Eureka, Consul, Kubernetes)
• Selects one instance (round-robin by default) and replaces the URL with the real host:port
• The instance list is cached locally; not fetched from the registry on every call

The staleness trap

• Instance list refreshed periodically, default 30 seconds
• A new instance registered in Eureka won't receive traffic for up to 30 seconds
• A terminated instance will still receive traffic for up to 30 seconds — connection refused is the signal
• Reduce the refresh interval with spring.cloud.loadbalancer.cache.ttl but don't go below 10 seconds — you hammer the registry
• Combine with Resilience4j retry to survive the staleness window without user-visible errors

The @LoadBalanced placement mistake

• @LoadBalanced goes on the @Bean method that defines the RestTemplate or WebClient.Builder
• Not on the injection point, not on the service class
• Without it, the LoadBalancerInterceptor is not registered; service name resolution fails with UnknownHostException
• This is the most common misconfiguration on first setup

Zone-aware routing for multi-AZ deployments

• spring.cloud.loadbalancer.zone = us-east-1a on each instance
• Prefers instances in the same availability zone; falls back when local instances unavailable
• Reduces cross-AZ latency (about 5–10 ms) and cross-AZ data transfer costs

Canary and A/B routing via custom ServiceInstanceListSupplier

• Implement a supplier that filters or weights instances based on metadata tags
• Route 10% of traffic to version=2.0 instances for canary rollout without touching gateway config
• Pure code change; no proxy redeploy

Client-side vs server-side

• Client-side: zero proxy hops, staleness window, JVM-only
• Server-side (Nginx, ALB): proxy hop per request, fresh routing data, all-language support
• Typical production stack: server-side at the edge (ALB + gateway), client-side for internal service-to-service calls

When to prefer client-side

• Internal service-to-service calls within a Spring Cloud cluster with Eureka or Consul already running
• High-volume internal traffic where eliminating the proxy hop matters
• Integration with Resilience4j and Micrometer Tracing is already present

When to prefer server-side

• Edge traffic from clients who don't participate in the service registry
• Polyglot clusters where non-JVM services need the same routing logic
• Centralized access logs, WAF, TLS termination

The strategic answer

• Client-side load balancing removes the proxy hop; staleness cache is the trade-off
• @LoadBalanced goes on the bean definition; the interceptor is what makes service names resolvable
• Tune cache ttl, add retry, consider zone-aware routing for multi-AZ
• Use both models in production: ALB at the edge, Spring Cloud LoadBalancer internally