Spring Cloud LoadBalancer vs Netflix Ribbon

The Spring Cloud ecosystem has been evolving significantly over the years. At first, it was mainly based on the Netflix stack, then it started shifting towards its own solutions. One of the components that has been substituted is Netflix Ribbon. Ribbon is a client-side load balancer and has been replaced by  Spring Cloud LoadBalancer.

Spring Cloud LoadBalancer is a more modern and maintainable solution. In this article, you will learn the differences between the two, their designs, and practical examples in Java.

Background

Spring Cloud once used Netflix Ribbon for client-side load balancing in its microservices architectures. It provided various load balancing algorithms:

• RoundRobinRule: Distributes requests sequentially in a circular manner. It is a good choice when the servers have the same capacity.
• RandomRule: Choose servers randomly
• AvailabilityFilteringRule: Skips servers that are in circuit-breaker tripped state or have high concurrent connections.
• WeightedResponseTimeRule: Calculates the average response time and assigns a weight to each server.
• ZoneAvoidanceRule: Calls zone and servers based on their performance.
• RetryRule: Retry failed servers after a defined time using one of the other rules.

Netflix officially deprecated Ribbon, and Spring Cloud introduced its own load balancer, a more mature and configurable solution that integrates better with the existing ecosystem, while providing the same algorithms described above.

Architecture Comparison

Ribbon integrates with Eureka for service discovery, maintaining its internal list of service instances. It can define load-balancing strategies with the help of external configuration.

In summary:

• It's part of the Netflix OSS stack (along with other components like Eureka, Hystrix, Zuul).
• Integrates well with Eureka
• Adopted by Spring Cloud in early versions.

Ribbon is based on the ILoadBalancer interface. The implementation of this interface allows the caller to choose from a list of servers, following certain rules. The default implementation is DynamicServerListLoadBalancer. This class works with a dynamic list of servers, keeps track of active server instances, and polls the service registry to keep the list updated.

Ribbon can get its server list from a hardcoded list (for testing use), or from a service registry like Eureka using a DiscoveryEnabledNIWSServerList component.

Spring Cloud LoadBalancer is part of the Spring ecosystem. Because of this, it integrates natively with Spring Boot and Spring Cloud Discovery services such as Eureka and Consul. It can be configured using the same model as Spring Boot. It also supports reactive programming.

• It is maintaned by the Spring team.
• It integrates natively with Spring Boot, Spring Cloud, and WebFlux.

The main architectural building blocks of Spring Cloud LoadBalancer are:

• Spring Cloud DiscoveryClient: It's an abstraction that allows the load balancer to fetch the list of services from registries like Eureka, Consul, Zookeeper.
• ServiceInstanceListSupplier: An interface which implementation is supposed to supply a list of service instance objects for a given service ID. It can be customized with filters (like zone preference).
• LoadBalancerClient / ReactiveLoadBalancer: There is a regular load balancer client for interfacing with MVC applications, and a reactive version for use with WebClient or Spring WebFlux.
• LoadBalancerInterceptor: Serves the purpose of intercepting HTTP requests.
• ReactorServiceInstanceLoadBalancer: Defines the strategy used by the load balancer. Two built-in strategies are RoundRobinLoadBalancer and RandomLoadBalancer. Custom implementations che be plugged in by providing a bean of type ReactorServiceInstanceLoadBalancer.

Configuration Example With Netflix Ribbon

Ribbon can be configured for interfacing Eureka by puttin some configuration in the application.yml file, and rely on Ribbon's automatic integration.

service-test:  
   ribbon:    
      NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

In Java, REST calls can be made through RestTemplate annotated with @LoadBalanced

@Bean 
@LoadBalanced 
public RestTemplate restTemplate() 
{
  return new RestTemplate(); 
}

//Example
String response = restTemplate.getForObject("http://service-test/endpoint", String.class);

Ribbon handles resolving the name service-test to one of the registered instances through Eureka.

Configuration Example With Spring Cloud LoadBalancer

The same functionality can be implemented with Spring Cloud LoadBalancer by defining a bean annotated with @LoadBalanced:

@Bean
@LoadBalanced 
public WebClient.Builder webClientBuilder() 
{    
  return WebClient.builder(); 
}
//Example 
String response = webClientBuilder.build()
  .get()
  .uri("http://service-test/endpoint")
  .retrieve()
  .bodyToMono(String.class)
  .block();

Spring Cloud LoadBalancer integrates with Spring's DiscoveryClient and uses a round-robin strategy by default.

Extending Load-Balancing Behavior

The approach by which Ribbon and Spring Cloud LoadBalancer allow custom strategies differs significantly. Ribbon needs to subclass existing rule classes.

public class CustomRule extends RoundRobinRule {
  @Override
  public Server choose(Object key) {
    return super.choose(key);
  } 
}

In Spring Cloud LoadBalancer, you define your own ReactorLoadBalancer.

@Bean
public ReactorLoadBalancer<ServiceInstance> customLoadBalancer(Environment env, LoadBalancerClientFactory factory) {
	return new MyCustomLoadBalancer(factory.getLazyProvider("service-test", ServiceInstanceListSupplier.class)); 
}

This provides more flexibility and better support for reactive flows.

Why the Shift?

The transition from Netflix Ribbon to Spring Cloud LoadBalancer was inevitable. It was part of a progressive removal of Netflix OSS components from the Spring Cloud ecosystem. Beside Ribbon becoming deprecated, it also played a role the Spring Cloud's emphasis on maintainability, testability, and native integration.

Spring Cloud LoadBalancer is better aligned with Spring Boot’s principles, has first-class support for both imperative and reactive stacks, and reduces external dependencies. It’s also actively maintained by the Spring team.

Conclusion

Ribbon served its purpose well in Spring Cloud applications for years, but Spring Cloud LoadBalancer is a better, more modern alternative. Its configuration is simplified, follows Spring idioms, and ensures long-term support and extensibility. It also aligns more naturally with Spring Boot’s reactive stack, making it a seamless fit for both blocking and non-blocking applications. Migrating to Spring Cloud LoadBalancer ensures a cleaner, more sustainable implementation of client-side load balancing.