Skip to content

Client-Side Load Balancing

TL;DR

Instead of routing through a middleman, the client picks which server to talk to directly. It's like having a contact list of all available servers and choosing one yourself. Fewer network hops, but it only works well when you control the clients. You're already using it — DNS is client-side load balancing.

Skipping the Middleman

Most people picture load balancing as a dedicated box sitting between clients and servers. But there's a simpler approach: let the client decide.

Think of it like ordering food. You could call a dispatcher who decides which pizza place to send your order to. Or you could just look up nearby pizza places yourself, pick one, and call them directly. Faster, no middleman — but you need to know which places are open.

With client-side load balancing, the client asks a service registry (a directory of available servers), gets back a list, and picks one. No extra hop on every request — just an occasional check-in to get an updated server list.

Example You Already Know: DNS

Here's the thing — you're already using client-side load balancing every time you open a website.

When your browser looks up api.example.com, the DNS server returns a list of IP addresses in a rotated order. Each person who looks it up gets a slightly different ordering, so traffic naturally spreads across servers.

It's like a phone directory that lists the same business at multiple locations — and shuffles the order each time you look it up, so different people call different branches.

The DNS Catch: Slow Updates

DNS entries have a ~~TTL~~ (time to live) — how long the address can be cached before checking again. If the TTL is 5 minutes and a server goes down, it could take up to 5 minutes before clients stop trying to reach it.

For initial traffic distribution, this is totally fine. For instant failover when servers crash, DNS alone isn't fast enough.

Example: Redis Cluster

Redis Cluster is a beautiful example of smart client-side load balancing.

Picture a library system with multiple branches, where each branch holds different books. When you walk in, any librarian can hand you a map: "Fiction is at the downtown branch, history is at the west branch, science is at the east branch."

That's how Redis Cluster works:

  1. Client connects to any node and asks "who's in this cluster and what data do they own?"
  2. Client caches the map — now it knows exactly which node has which data
  3. Client goes directly to the right node for each request — no middleman

And if the client accidentally picks the wrong node? Redis politely says "That's not mine — try Node 3" (a MOVED response). The client updates its map and retries. Self-correcting and elegant.

When Client-Side Load Balancing Works

It fits two scenarios really well:

1. A small number of clients you control. Like microservices in your backend talking to each other, or applications talking to a Redis Cluster. You control the client code, so you can build in the logic to fetch server lists and pick intelligently.

2. Lots of clients where slow updates are acceptable. DNS is the perfect example. Millions of clients, each caching the server list for a few minutes. If a server goes down, it takes a bit for everyone to notice, but that's usually okay.

Client-Side Load Balancing Decision

When It Doesn't Work

Client-side load balancing falls apart when:

  • You don't control the clients — You can't make random browsers on the internet implement your load balancing logic
  • You need instant failover — If a server goes down and you can't afford even seconds of errors, you need something faster than client-side discovery
  • You need smart routing — Directing requests based on URL path, cookies, or headers requires something that can inspect the request

For these cases, you need a dedicated load balancer — which is what we'll cover next.

Interview Tip

Mentioning client-side load balancing in an interview is a nice way to show depth. Most candidates only talk about dedicated load balancers. If you're designing a microservice architecture and say "these internal services can use client-side load balancing with a service registry — it avoids the extra hop of a dedicated LB for service-to-service calls," that demonstrates real-world awareness. gRPC has this built in, which is a good detail to drop.