Centralized, In‑Process, or Independent: Which Microservice Load‑Balancing Works Best?

01 Centralized LB

In this approach an independent load balancer sits between service consumers and providers, often implemented with hardware (e.g., F5) or software (e.g., LVS, HAProxy). The LB maintains a mapping of service addresses, configured by operations, and forwards requests based on a strategy such as round‑robin. It also performs health checks to remove unhealthy instances. Consumers discover the LB typically via a DNS name pointing to the LB. This solution is simple to implement and allows centralized access control, but it introduces a single point of failure and adds an extra network hop, which can become a bottleneck under high traffic.

02 In‑Process (Soft) Load Balancing

This pattern moves the load‑balancing logic into the client process, often called soft load balancing. It requires a service registry (e.g., Zookeeper, Consul, Etcd) that supports self‑registration and health checks. When a service starts, it registers its address and periodically sends heartbeats. The client queries the registry (caching results) to obtain a list of instances and selects one using a load‑balancing algorithm. This eliminates the extra hop and improves performance, but it demands a highly available registry and introduces client‑side library implementations for each language stack, increasing development and maintenance effort. Upgrading the client library also requires code changes and redeployment.

Typical examples include Netflix’s open‑source stack: Eureka for service registration, Karyon for server‑side registration and health checks, and Ribbon for client‑side discovery and soft routing. Alibaba’s Dubbo also follows a similar mechanism.

03 Independent LB Process

This hybrid approach extracts the load‑balancing and discovery functions into a separate process on each host. Multiple services on the same machine query the same independent LB process, which interacts with a shared service registry. The LB process handles health checks and routing, while service callers communicate with it via local inter‑process calls, preserving performance and avoiding the need for language‑specific client libraries. Deployment is more complex and debugging can be harder, but failures are isolated to the host. A typical case is Airbnb’s SmartStack, which uses Zookeeper as the registry, Nerve as the independent LB process for registration and health checks, and Synapse/HAProxy as the routing component.