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.
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
- nginxnginx is a fast web server and reverse proxy that also works as a load balancer and HTTP cache.
- CaddyCaddy is a web server and reverse proxy written in Go with automatic HTTPS and very simple configuration.
- TraefikTraefik is a cloud-native reverse proxy and edge router that discovers services in Docker and Kubernetes and configures routes itself.
- KubernetesKubernetes is a container orchestration system that deploys, scales and heals applications across a cluster of servers.
- AWSThe largest cloud platform, with hundreds of services from virtual machines and storage to databases, queues and ML.
- CloudflareA global network with CDN, DNS, DDoS protection, plus Workers, R2 and D1 for running apps at the edge.
Related topics
Sources
Logos belong to their owners and are used for identification only. Icons: Simple Icons (CC0), Devicon (MIT).