Load Balancer

A load balancer is a software (or hardware) component that distributes network traffic across multiple servers. It improves performance and reliability by sharing load and providing redundancy. Without a load balancer, a website relies on a single server—which may be acceptable for low traffic but quickly becomes a bottleneck as traffic grows. A single server is also a single point of failure: if it goes down, the site becomes unavailable. One strong option for HTTP load balancing is NGINX. It provides flexible routing, multiple balancing algorithms, and built‑in failure handling to keep traffic flowing to healthy backends.

By default, NGINX performs passive health checks: when repeated connection failures or timeouts occur for a backend, NGINX marks that server unavailable and stops sending new requests to it. For active, configurable health checks, use NGINX Plus or third‑party modules.

A diagram titled "Load Balancing With Nginx" showing users connecting through a network cloud to an NGINX load balancer which distributes traffic to multiple web servers. Health-check lines indicate some servers are healthy (green) while one shows failing status (red) with an alert.

Because unhealthy backends are removed from rotation, users are not routed to servers that are down. If one or two servers fail, the website can stay online while you repair the affected machines. Common NGINX load-balancing algorithms

Round Robin — default. Distributes requests sequentially across the backend pool.
Weighted Round Robin — assigns different weights so stronger servers receive more requests.
IP Hash (sticky sessions) — routes requests from the same client IP to the same backend.
Least Connections — picks the backend with the fewest active connections.
Least Time — (NGINX Plus) chooses the backend with the lowest estimated response time.

Below are explanations, diagrams, and configuration examples for each algorithm. Algorithms: Round Robin Round Robin distributes requests in turn across the backend pool: request 1 → server A, request 2 → server B, request 3 → server C, then back to server A. Use it when backend servers have similar capacity and host the same content.

A diagram titled "Algorithms: Round Robin" showing an NGINX load balancer using a round‑robin method to distribute requests to three numbered web servers. Arrows indicate sequential routing of traffic to servers 1, 2, and 3.

Define an upstream pool and reference it with proxy_pass. Upstream blocks must live in the http context (or in a file included by nginx.conf). Example Round Robin upstream and proxy configuration:

upstream backend {
    server 10.10.0.101:80;
    server 10.10.0.102:80;
    server 10.10.0.103:80;
}

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://backend/;
    }
}

It’s common to place the upstream definition in the same file that references it for readability, but you can also include it from a separate file. Weighted Round Robin Weighted Round Robin behaves like Round Robin but lets you assign different weights to backends so some servers receive a larger share of requests. Useful when hosts have different CPU/memory resources.

A diagram titled "Algorithms: Weighted Round Robin" showing an NGINX load balancer sending traffic through a weighted round-robin algorithm to three web servers labeled with weights 4, 2, and 1. The graphic illustrates distributing requests proportionally to server weights.

Example weighted configuration (first server gets 4× the requests of the third, and 2× the requests of the second):

upstream backend {
    server 10.10.0.101:80 weight=4;
    server 10.10.0.102:80 weight=2;
    server 10.10.0.103:80 weight=1;
}

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://backend/;
    }
}

Sticky Sessions (ip_hash) When session state is stored locally on a backend (for example, in-memory shopping cart), you often want the same client to return to the same backend. NGINX’s ip_hash provides simple session affinity by mapping a client IP to a backend. How it works: NGINX uses the client IP to select a server; subsequent requests from that IP go to the same backend while it remains healthy.

A diagram titled "Algorithms: IP Hash" showing an NGINX load balancer using an IP-hash method to route requests. Arrows from an IP-location icon point to three web servers in a server pool.

Example using ip_hash:

upstream backend {
    ip_hash;
    server 10.10.0.101:80;
    server 10.10.0.102:80;
    server 10.10.0.103:80;
}

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://backend/;
    }
}

ip_hash has limitations: clients behind NAT will share the same IP (causing uneven distribution), and changes to the backend pool can remap IPs to different servers. For robust session persistence consider client cookies, a shared session store (Redis), or sticky cookie modules.

Least Connections The least_conn algorithm sends each new request to the backend with the fewest active connections. This makes distribution fairer when connections have varying durations (e.g., long polling or streaming).

A diagram titled "Algorithms: Least Connection" showing an NGINX load balancer using the least-connection method to route traffic to one of several web servers. Arrows from the load balancer point to three servers (labeled 2, 5, 4), indicating it sends requests to the server with the fewest active connections.

Example:

upstream backend {
    least_conn;
    server 10.10.0.101:80;
    server 10.10.0.102:80;
    server 10.10.0.103:80;
}

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://backend/;
    }
}

Least Time (NGINX Plus) least_time selects the backend that is expected to return the full response the fastest, using response time metrics (for example, last_byte or header). This algorithm is available in NGINX Plus.

A diagram showing an NGINX load balancer using a "Least Time" algorithm (stopwatch icon) to route traffic to multiple web servers. Arrows indicate requests being distributed from the load balancer/algorithm to three backend servers.

Example NGINX Plus configuration:

upstream backend {
    least_time last_byte/header;
    server 10.10.0.101:80;
    server 10.10.0.102:80;
    server 10.10.0.103:80;
}

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://backend/;
    }
}

With least_time, NGINX Plus evaluates which server can finish delivering the full response fastest, using timing metrics such as time to first byte or time to last byte based on the chosen options. Quick comparison table

Algorithm	When to use	Notes
Round Robin	Backends are homogeneous	Default, simple and efficient
Weighted Round Robin	Backends have different capacity	Assign `weight=` per server
`ip_hash`	Need simple session affinity	Limited with NAT; use cookies or shared store for reliability
`least_conn`	Requests have varying duration	Balances connection load rather than request count
`least_time` (Plus)	Optimize for fastest overall response	Requires NGINX Plus; uses response timing metrics

Next steps After learning the main algorithms (Round Robin, Weighted Round Robin, ip_hash, least_conn, and least_time), you can try implementing them in a staging environment and measure metrics such as response time, error rate, and connection distribution. For more advanced scenarios, explore active health checks, session persistence strategies, and NGINX Plus features. References and further reading

NGINX official docs: https://nginx.org/en/docs/
NGINX Plus load balancing: https://www.nginx.com/products/nginx/
Session persistence strategies: consider cookie‑based affinity or centralized session stores (e.g., Redis) for scalable stateful applications.

Introduction

Install & Config

Intermediate Config

Security

Performance

Conclusion

Watch Video