A DigitalOcean Load Balancer doesn’t actually "balance" traffic in the way you might intuitively think; it simply forwards incoming requests to one of your Droplets based on a simple round-robin algorithm.
Let’s see this in action. Imagine you have two Droplets, 192.0.2.1 and 192.0.2.2, both running a web server. You create a DigitalOcean Load Balancer with a public IP address of 192.0.2.100 and configure it to forward HTTP traffic (port 80) to your Droplets on port 80.
When a user requests http://192.0.2.100:
- The request hits the Load Balancer.
- The Load Balancer checks its configuration. It sees that HTTP traffic on port 80 should be forwarded to a backend pool consisting of
192.0.2.1:80and192.0.2.2:80. - It picks the first available Droplet in the pool. Let’s say it’s
192.0.2.1. - The Load Balancer forwards the request to
192.0.2.1:80. - The web server on
192.0.2.1responds. - The Load Balancer sends the response back to the user.
The next time a request comes in for http://192.0.2.100, the Load Balancer will pick 192.0.2.2 (assuming it’s healthy), then 192.0.2.1 again, and so on. This is the "round-robin" distribution.
The core problem a load balancer solves is availability and scalability for stateless applications. If your application is stateless (meaning it doesn’t store session data locally on the server), you can add or remove Droplets behind the load balancer without interrupting service. If one Droplet fails, the load balancer stops sending traffic to it, and your application remains accessible via the other Droplets.
The internal workings are fairly straightforward: the Load Balancer acts as a proxy. It has its own public IP address. When traffic arrives, it inspects the destination IP and port, then consults its configured rules to determine which backend Droplet(s) to send the traffic to. Health checks are crucial here. The load balancer periodically pings your backend Droplets to ensure they’re responsive. If a Droplet fails a health check, it’s temporarily removed from the rotation until it becomes healthy again.
The primary levers you control are:
- Frontend Configuration: This defines the public IP address of the load balancer and the protocols/ports it listens on (e.g., HTTP on port 80, HTTPS on port 443).
- Backend Pool: This is the list of Droplets (and their ports) that will receive traffic.
- Health Checks: These are the rules for determining if a backend Droplet is healthy. You configure the protocol (HTTP, TCP, HTTPS), port, request path (for HTTP/S), and intervals/timeouts. For example, a common HTTP health check might be to request
/healthon port 80 every 10 seconds, expecting a 200 OK response within 5 seconds.
When setting up HTTPS, the load balancer can handle SSL termination. This means you upload your SSL certificate and private key to the load balancer. It then decrypts incoming HTTPS traffic and forwards it as unencrypted HTTP to your backend Droplets. This simplifies certificate management, as you only need to update it on the load balancer, not on every individual Droplet.
A common misconception is that load balancers perform sophisticated traffic distribution algorithms beyond simple round-robin. While some advanced load balancing solutions offer weighted distribution, least connections, or IP hashing, DigitalOcean’s basic Load Balancer primarily uses round-robin for its backend pools. For more complex routing, you’d typically look at solutions like Nginx or HAProxy running on a dedicated Droplet.
The next concept you’ll likely encounter is how to manage persistent sessions if your application isn’t stateless, which involves sticky sessions or using a shared session store.