Algorithms, affinity, and state | Load balancing: traffic and resilience

Concept and mechanism

Round-robin distributes requests or connections according to implementation scope. Weights can reflect relative capacity: in an ideal model with weights three and one, the first share is 3/4, or 75%. Actual measurement depends on eligibility, affinity, duration, and workload. NGINX least_conn considers active connections and weights without automatically measuring CPU or each request cost. When some connections last minutes, similar new-connection counts can produce different occupancy. Compare the algorithm signal with the constraint you want to manage. An algorithm name does not replace observation of latency, errors, queues, and resources by backend.

Guided application

Affinity attempts to retain a client on one target, but the observed key can group users. Shared NAT concentrates origins under one IP and can skew ip_hash. A sticky cookie can also keep tests on the old backend during a release. Identify the actual target of each sample. Affinity does not replicate sessions held in memory: if the process disappears, state and recovery need a design. Consistent hashing can reduce remapping when membership changes but guarantees neither zero changes nor data copying. In a fictional long-connection case, evaluate least_conn using the same workload before promising improvement and establish the limits of each server.

IN PRACTICE

Equal counts do not prove equal work; affinity does not prove replicated state.

Common pitfalls

Weight as created capacity; IP as unique user; sticky as replication; consistent hash as zero remapping.

Related topics: Routing and TLS boundaries · Health checks and readiness · Retries, limits, and client origin

Take this idea with you

Choose the appropriate signal and validate distribution and state separately.

Create account

Reference: NGINX HTTP load-balancing methods · DR load balancing 2026-09; selected NGINX, HAProxy 3.2, Kubernetes and AWS ALB behavior