Every load balancer has to answer the same question thousands of times a second: which backend gets this request? The scheduling algorithm is the policy behind that answer, and while the default will usually work, "usually works" and "works well for your traffic" are not the same thing.
Tula supports six algorithms, configurable per Virtual IP and changeable at any time. Here is what each one actually does, and — more usefully — how to decide which one fits your workload.
The contenders
Round Robin
The default. Requests are distributed sequentially and evenly across all healthy backends, cycling through the pool in order. Every backend receives an equal share of traffic regardless of its current load or response time.
Round Robin’s assumption is that all requests cost roughly the same and all servers are roughly identical. When both hold — a fleet of identical web servers serving similar pages — it is simple, predictable, and hard to beat.
Weighted Round Robin
The same rotation, but each backend carries a numeric weight and receives traffic in proportion to it. A server with weight 3 gets three times the traffic of a server with weight 1.
Use this when your backends are not identical: a pool mixing newer and older hardware, or instances of different sizes. The weights let the stronger machines absorb a proportionally larger share.
Least Connections
Each new request goes to the backend with the fewest active connections. Rather than assuming uniformity, this algorithm measures load — or at least a workable proxy for it — and adapts in real time.
It shines when request durations vary widely. An API serving a mix of lightweight reads and heavy computation will, under Round Robin, occasionally pile several expensive requests onto one unlucky server. Least Connections naturally steers new work away from busy backends.
Weighted Least Connections
The adaptive behaviour of Least Connections combined with capacity weighting: the scheduler picks the backend with the lowest ratio of active connections to assigned weight. This accounts for both current load and server capacity, making it the most adaptive general-purpose choice when your pool mixes hardware sizes and your requests vary in cost.
Source IP Hash
A hash of the client’s source IP address deterministically maps each client to a backend. As long as the set of healthy backends is stable, a given client IP always lands on the same server.
This is persistence by mathematics rather than by memory: no cookies, no state tables. It works for any protocol, which makes it the go-to for Layer 4 services needing client affinity — FTP being a classic example. The caveat is NAT: an office of five hundred people behind one gateway looks like a single client, and they will all be pinned to one backend.
URI Hash
A hash of the request URI maps each URI to a backend, so requests for the same resource always hit the same server. This is only available on Layer 7 (HTTP/HTTPS) VIPs, because the load balancer must parse the request to see the URI.
The payoff is cache efficiency. If your backends maintain local caches — caching proxies, content servers — URI Hash means each object is cached on exactly one backend rather than duplicated across all of them, which can dramatically improve hit rates.
A decision path
Rather than memorising six descriptions, walk through four questions:
1. Do clients need to keep hitting the same backend?
If your application stores session state locally and you are on a Layer 4 VIP, choose Source IP Hash. (On Layer 7, cookie-based persistence is usually a better answer than hashing, because it identifies clients reliably even behind shared NAT.)
2. Are your backends caching content locally?
For cache-heavy workloads behind an L7 VIP, URI Hash maximises hit rates.
3. Do request costs vary significantly?
If some requests take milliseconds and others take seconds, pick Least Connections — or Weighted Least Connections if your servers also differ in capacity.
4. Otherwise: are your servers identical?
Identical servers, uniform requests: Round Robin. Mixed hardware, uniform requests: Weighted Round Robin.
The comparison at a glance
| Algorithm | Distribution | Server affinity | Best for |
|---|---|---|---|
| Round Robin | Equal | None | Uniform workloads, identical servers |
| Weighted Round Robin | Proportional to weight | None | Mixed-capacity servers, uniform requests |
| Least Connections | Adaptive | None | Variable request duration |
| Weighted Least Connections | Adaptive + weighted | None | Mixed capacity and variable duration |
| Source IP Hash | Hash-based | By client IP | L4 persistence |
| URI Hash | Hash-based | By request URI | Caching proxies, static content |
Common mistakes worth avoiding
Reaching for Least Connections "because it’s smarter". Adaptive algorithms are only better when there is variability to adapt to. For uniform traffic they behave much like Round Robin, and Round Robin’s perfectly even rotation is easier to reason about when you are staring at per-backend graphs during an incident.
Using Source IP Hash for general web traffic. Corporate NAT gateways, mobile carrier-grade NAT, and VPN concentrators all collapse thousands of users into a handful of source IPs. Your "balanced" pool ends up with one backend doing half the work. If you need stickiness on HTTP, use cookie persistence instead.
Setting weights once and forgetting them. Weights encode a claim about relative capacity. When you replace hardware or resize instances, revisit them — stale weights quietly skew your distribution for months.
Ignoring what the statistics are telling you. Uneven backend distribution in the Monitoring dashboard is often the first sign of a mismatch between algorithm and workload — or of a health check problem concentrating traffic on a subset of the pool.
Changing your mind is cheap
The algorithm is configured per VIP, and you can change it at any time: adjust the setting, apply the configuration, and the new policy takes effect. That makes experimentation low-risk. If response times climb under Round Robin while connection counts stay level, try Least Connections for a week and compare the per-backend graphs.
Start simple, measure, and let the evidence — not the feature list — decide. The full reference for each algorithm lives in the algorithms documentation, and the quick start guide covers creating your first VIP end to end.
