Choosing the Right Load Balancing for Microservices: Centralized, In‑Process, Independent

Microservice architecture consists of many fine‑grained services that communicate via lightweight mechanisms, which introduces service registration and discovery, load balancing, and health‑check concerns.

01 Centralized Load Balancer

An independent load balancer (hardware like F5 or software such as LVS, HAProxy) holds a mapping of service addresses. Clients discover the LB via DNS. The LB performs load‑balancing (e.g., round‑robin) and health checks. Drawbacks include a single point of failure and added latency.

02 In‑Process Load Balancer (Soft Load Balancing)

This approach embeds the LB logic inside the client process, requiring a service registry (e.g., Zookeeper, Consul, Etcd) for self‑registration and discovery. The client queries the registry, caches the address list, applies a balancing strategy, and calls the target directly, avoiding extra hops. It demands a highly available registry and incurs development overhead for multiple language client libraries; upgrades also require code changes. Examples: Netflix Eureka with Karyon and Ribbon, Alibaba Dubbo.

03 Independent LB Process

A compromise that runs a separate LB process on each host. Services on the same host query this local LB for discovery and balancing, using a registry (e.g., Zookeeper) for health checks. It eliminates the single‑point failure of a centralized LB, avoids client‑side libraries, and simplifies upgrades, though deployment is more complex. Example: Airbnb SmartStack with Zookeeper, Nerve, and Synapse/HAProxy.