Load Balancer

Load balancer is a network component that distributes incoming requests across a pool of backend servers so that no single machine is overwhelmed. Functionally it acts as a reverse proxy: clients connect to one front-end address, and the balancer forwards each connection to a healthy backend according to a distribution policy. By spreading work and continuously checking server health, it lets a self-hosted service scale horizontally and survive the failure of any individual node.

Layer 4 versus Layer 7

Load balancers operate at one of two layers. A Layer 4 balancer routes purely on network information such as IP address and TCP or UDP port, which is fast, simple, and protocol-agnostic — it never inspects what the bytes mean. A Layer 7 balancer understands the application protocol and can route on HTTP details like the requested URL, host header, or cookies, enabling smarter rules such as sending API traffic to one pool and static assets to another; the price is that it terminates connections and does more work per request, often including TLS termination so certificates live in one place instead of on every backend. Common distribution methods include round robin, weighted round robin for servers of different sizes, least-connections for uneven workloads, and IP-hash for basic session stickiness when a client should keep hitting the same backend.

Health checks and availability

The defining feature is the health check. The balancer periodically probes each backend — a TCP connect at Layer 4, a real HTTP request against a status endpoint at Layer 7 — and automatically stops sending traffic to any node that becomes slow or unresponsive, rerouting users to healthy servers so the outage is invisible. This is what turns a cluster of ordinary machines into a highly available service, and it enables graceful operations too: drain a backend, patch it, and return it to the pool with no user-visible downtime. The balancer itself then becomes the obvious single point of failure, which mature setups address with a redundant pair sharing a floating address, and larger footprints extend with anycast for cross-region distribution.

In the sovereign stack

Honest sizing matters: most home-lab services do not need a load balancer — a single reverse proxy in front of single-instance apps is the right amount of infrastructure, and adding a balancing tier just adds moving parts. It earns its place when a service outgrows one machine or one machine's failure becomes unacceptable: a pair of self-hosted AI inference servers behind one endpoint, replicated Electrum or API servers backing a public service, or a monitoring stack that must survive a host dying. Battle-tested open-source implementations (HAProxy, nginx, and kin) mean the capability costs nothing but configuration, and the balancer is frequently the only host that needs to sit exposed in a DMZ while the real backends stay on private addresses behind the firewall. That pattern — one hardened, replaceable front door; the valuable machines unreachable behind it — is load balancing's quiet second job: not just spreading traffic, but shrinking the attack surface of everything it protects.

Miners already use the core idea without naming it: the primary/backup pool slots in every machine's configuration are health-checked failover — detect a dead endpoint, shift work to a live one — which is a load balancer's logic applied from the client side rather than the server's. Recognizing the pattern helps when your fleet's monitoring, API, or dashboard services grow beyond one box: the same principle that keeps hashrate flowing when a pool endpoint dies keeps your own services answering when a host does. Infrastructure ideas repeat at every scale; the operators who notice the repetition get to reuse what they already understand instead of learning each layer from scratch.