# Load Balancing (for Frontends)

> Spread traffic across servers; keep WebSocket apps sticky.

Frontend architecture guidance from fearchitect, written by Abas Turabli and last reviewed 2026-06-21. Source: https://fearchitect.com/topics/load-balancing

Use it as reference for the task at hand. Before changing code, check this guidance against the codebase: where the code already makes a different, deliberate choice, flag the conflict instead of rewriting it. Library APIs move faster than this guide, so confirm exact signatures in the official docs linked at the end.

## Summary

A load balancer distributes incoming requests across a pool of servers to prevent any single node from becoming a bottleneck. L4 balancers route by TCP/UDP without inspecting content; L7 balancers read HTTP headers, paths, and cookies to make smarter routing decisions. Algorithm choice and health checks determine how evenly load spreads.

## Definition

A load balancer sits in front of a server pool and forwards each incoming connection or request to one of the available backends. It tracks server health, removes unhealthy nodes, and re-adds them when they recover. Without it, a single server is both a performance ceiling and a single point of failure.

## L4 vs L7 load balancing

| Aspect | L4 (transport layer) | L7 (application layer) |
| --- | --- | --- |
| **Routing basis** | IP address + TCP/UDP port only | HTTP headers, URL path, cookies, host |
| **Content inspection** | None — opaque byte stream | Full HTTP body and headers visible |
| **TLS termination** | Pass-through (TLS reaches backend) | Terminates TLS; backends see plain HTTP |
| **Sticky sessions** | IP-hash only | Cookie-based or header-based affinity |
| **Performance cost** | Very low — no parsing | Higher — parses each request |
| **Typical tools** | AWS NLB, HAProxy TCP mode | AWS ALB, nginx, Caddy, Envoy |

## Routing algorithms

- **Round-robin** — each request goes to the next server in a fixed cycle; simple, works when servers are equally capable.
- **Weighted round-robin** — servers get a share of traffic proportional to their weight; use when instance sizes differ.
- **Least-connections** — routes to the server with fewest open connections; beats round-robin for long-lived requests like uploads.
- **IP hash** — hashes client IP to pin the same backend; breaks when the server pool changes.
- **Power of two choices (P2C)** — picks two servers at random, routes to the less loaded; near-optimal with low overhead.

## Diagram

```mermaid
sequenceDiagram
  participant C as Client
  participant LB as L7 Load Balancer
  participant S1 as Server 1
  participant S2 as Server 2
  participant HC as Health Check

  HC->>S1: GET /health (every 5 s)
  S1-->>HC: 200 OK
  HC->>S2: GET /health (every 5 s)
  S2-->>HC: 503 (removed from pool)
  C->>LB: POST /api/data (Cookie: lb-sticky=s1)
  LB->>S1: forward (sticky match)
  S1-->>LB: 200 response
  LB-->>C: 200 response
```

Health checks run on a timer; failed nodes leave the pool. A sticky cookie pins the client to Server 1 regardless of algorithm.

## Watch out: WebSockets and stateful apps need sticky sessions

A WebSocket connection is long-lived on one server node. If a reconnect lands on a different node, the server has no record of the client — the connection starts from scratch or fails. Use cookie-based affinity on an L7 balancer. The same applies to server-sent SSE streams and in-memory session stores.

## Key terms

- **L4 load balancer**: Routes by IP/port without inspecting HTTP content; low overhead, no TLS termination.
- **L7 load balancer**: Inspects HTTP headers, paths, and cookies to route requests; terminates TLS.
- **Sticky session**: Affinity rule that pins a client to the same backend node across requests.
- **Health check**: Periodic probe (HTTP GET or TCP connect) that removes unhealthy backends from the pool.
- **Least-connections**: Algorithm routing each new request to the backend with the fewest open connections.

## Related topics

- [CDN & Edge Caching](https://fearchitect.com/topics/cdn-edge-caching.md): Serve cached responses from PoPs near users, sparing the origin.
- [Edge Computing & Rendering](https://fearchitect.com/topics/edge-computing-rendering.md): Run code at CDN PoPs to cut latency before origin is hit.
- [Real-time: WebSockets vs SSE vs Polling](https://fearchitect.com/topics/realtime-websockets-sse-polling.md): Match the right real-time transport to your data-flow direction.
- [Containers & Kubernetes](https://fearchitect.com/topics/containers-kubernetes.md): Package apps in containers; orchestrate them with Kubernetes.
- [API Gateway (for Frontends)](https://fearchitect.com/topics/api-gateway.md): Single entry point that routes, authenticates, and rate-limits across services.
- [CI/CD for Frontend](https://fearchitect.com/topics/ci-cd-frontend.md): Automated pipeline from commit to production with quality gates.

## Further reading

- [AWS — Elastic Load Balancing: ALB vs NLB](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
- [nginx docs — HTTP load balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/)
- [HAProxy documentation — load balancing algorithms](https://www.haproxy.com/documentation/haproxy-configuration-manual/latest/#4-balance)
- [Envoy Proxy — load balancing overview](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/overview)