Building block

Load balancer

Spreads requests across several copies of a service and takes failed ones out of rotation. The first step to horizontal scaling and zero downtime deploys.

A load balancer spreads requests across three app copiesHTTPShealth ✗ClientsLoad balancerApp copy 1App copy 2App copy 3 (down)Database
A load balancer spreads requests across three app copies

L4 and L7

An L4 balancer works at the TCP/UDP level: it sees IPs and ports, but not HTTP. It is very fast and cheap and fits any protocol (databases, gRPC, WebSocket). Examples: AWS NLB, HAProxy in TCP mode, Linux IPVS.

An L7 balancer understands HTTP: it routes by path and headers (/api to one pool, /static to another), terminates TLS, adds headers and retries. Examples: Nginx, Caddy, Traefik, Envoy, AWS ALB.

Balancing algorithms

Round robin hands requests to each copy in turn, simple and good for similar short requests. Least connections sends a request to the copy with the fewest active connections and works better when requests vary in duration (say, generating a PDF certificate next to a regular API call).

Consistent hashing binds a key (user id, URL) to a specific backend, and adding a node remaps only a small share of keys. This is useful for caches and stateful services.

Health checks and zero downtime deploys

The balancer calls /healthz on each copy every few seconds. After 2 or 3 failed checks the copy leaves rotation, and users never see it.

Rolling deploys build on this: the new version starts alongside, passes the health check and joins the pool, while the old one first stops receiving new requests (draining), waits for current ones to finish and only then stops.

One key condition: copies must be stateless. If the session lives in process memory, the user gets «logged out» when routed to another copy. Keep state in the database, Redis or a token. Sticky sessions help for a while but break even distribution.

Pros

  • Horizontal scaling by adding copies.
  • Unhealthy copies are removed automatically.
  • Zero downtime deploys via rolling updates.
  • One place for TLS, compression and routing.

Cons

  • The balancer itself can become a single point of failure, so you need a pair or a managed service.
  • Requires a stateless application.
  • Another layer of configuration and a few more milliseconds of latency.

When to choose it

  • The service must run on more than one copy.
  • You need zero downtime deploys.
  • Different paths must route to different backends.

Where it is used

  • GitHub: its own GLB load balancer, described on the company blog in 2016.
  • Cloudflare: the Unimog L4 load balancer on every server of its edge network (2020).

Tools

Sources

Logos belong to their owners and are used for identification only. Icons: Simple Icons (CC0), Devicon (MIT).