Blog
3 min read

What Is a Load Balancer? Spreading Traffic Across Servers

A load balancer sits in front of several copies of your app and spreads requests between them, skipping any that are unhealthy. How it works, the common algorithms, sticky sessions, health checks, and why a small app probably doesn't need one yet.

When one server can't handle all your traffic — or you don't want one failure to take your app down — you run several copies of your app. A load balancer sits in front of them and decides which copy handles each request.

Visitors only ever see the load balancer's address. Behind it, there might be two servers or two hundred.

What it does

  1. Spreads traffic. Each request goes to one of the copies ("backends" or "upstreams"), so none is overwhelmed.
  2. Checks health. It regularly pings each backend — often a health check endpoint like /healthz. If one stops responding, traffic stops going to it.
  3. Enables zero-downtime deploys. Take one copy out, update it, put it back, repeat. (Zero-downtime deploys)
  4. Often handles HTTPS so backends don't each need certificates.

How it chooses a backend

Method How it works Good for
Round robin Takes turns: A, B, C, A, B, C… Identical servers, similar requests
Least connections Sends to whichever is least busy Requests of very different lengths
Weighted Bigger servers get more traffic Mixed server sizes
IP hash Same visitor IP → same server Basic stickiness

Round robin is the common default and works well when backends are identical.

Layer 4 vs Layer 7

You'll see these terms in cloud dashboards:

  • Layer 4 (TCP) — forwards raw connections without looking inside. Very fast; works for any protocol (databases, game servers).
  • Layer 7 (HTTP) — reads each HTTP request, so it can route by path or domain (/api → API servers, / → web servers), add headers, and handle HTTPS.

Most web apps use Layer 7. Nginx, Caddy, HAProxy and Traefik can all act as Layer 7 load balancers; cloud providers sell managed ones. (Reverse proxies explained, what is Nginx?)

The catch: your app must be stateless

If a user's request might land on any server, then no server can keep important state only in its own memory or disk:

  • Sessions stored in one server's memory are missing on the others. Store them in the database or Redis, or use signed cookies. (Session cookies vs JWTs)
  • Uploaded files on one server's disk are missing on the others. Use object storage. (What is object storage?)
  • Scheduled jobs run once per server — three servers, three emails. Run them on one worker. (Background jobs)
  • WebSockets connect to one server; broadcasting to all users needs a shared channel like Redis pub/sub.

Sticky sessions (always sending the same user to the same server) can paper over some of this, but they make balancing uneven and fail when that server dies. Fixing the state is better.

Do you need one?

For most small apps: not yet. A single well-sized server handles far more traffic than most people expect, especially with a CDN in front of static files. Adding a load balancer adds cost, moving parts, and the stateless requirements above.

You need one when:

  • One server genuinely can't keep up, even after optimisation and a bigger size. (Horizontal vs vertical scaling)
  • Downtime from a single server failing is unacceptable.
  • You need to deploy without any interruption.

The summary

  • A load balancer spreads requests across copies of your app and skips unhealthy ones.
  • Round robin and least-connections are the common methods.
  • It requires your app to keep no important state on individual servers.
  • Small apps usually scale up one server first, and add a load balancer later.

EasySpawn gives each app a dedicated server you can resize as it grows — the simple way to scale — with your database and backups alongside. See pricing or join the waitlist.

Related: Horizontal vs Vertical Scaling · Reverse Proxies Explained · Health Check Endpoints · What Is a Server?

Keep reading