How big systems spread the work — fairly and without chaos

1 Load balancers & their types

Recall from Session 1 that we scale a system horizontally by running many identical copies of our server. A load balancer (LB) is the piece that sits in front of those copies and decides which one gets each incoming request. It gives us three superpowers at once:

• Spreading load — no single server gets overwhelmed. It distributes the load (requests and data) equally across the app/DB servers behind it.
• High availability — if one server dies, the LB stops sending traffic to it, and users never notice.
• A single, unified front door — clients talk to one address (the LB) instead of needing to know about every server behind it. This gives the end user a unified view of the entire backend: the user doesn't care which exact server handles their request.

L4 vs L7 — two places the LB can do its job

Load balancers are usually described by which OSI layer they operate on. The OSI model is just a 7-layer map of how network data travels; you only need two layers here. Layer 4 (L4) is the transport layer — it deals with TCP/UDP connections, IP addresses, and ports. Layer 7 (L7) is the application layer — it understands HTTP, so it can read URLs, headers, and cookies.

Hardware vs software load balancers

Historically, load balancers were expensive dedicated hardware appliances (think specialized boxes from vendors like F5 or Citrix) that you bought and racked in your data center. Today most teams use software load balancers — programs running on ordinary servers — or a cloud-managed LB you rent by the hour. On AWS the cloud-managed option is the Elastic Load Balancer (ELB).

Health checks — how the LB knows who's alive

A load balancer must never send a request to a dead server. So it constantly runs health checks: it periodically pings each backend (often a tiny HTTP request to a special URL like /healthz) and waits for an "I'm OK" reply.

• If a server answers correctly → it stays in the rotation ("healthy").
• If it fails a few checks in a row → the LB marks it "unhealthy" and stops routing traffic to it. Users never hit the broken box.
• When it starts answering again → the LB quietly adds it back.

# The backend exposes a cheap "am I alive?" route
GET /healthz  # LB calls this every few seconds

# Healthy response:
200 OK   {"status": "ok"}

# If the server is overloaded or broken:
503 Service Unavailable   # → LB pulls it out of rotation

2 A detour: IP addresses

Before we decide which server a request goes to, it helps to remember how machines are even addressed. An IPv4 address looks like 142.250.192.4 — four numbers separated by dots, each in the range 0–255.

# IPv4 layout: four octets, each 0–255
IPv4:  0-255 . 0-255 . 0-255 . 0-255

# Each octet is 8 bits, so total possibilities:
2^8 * 2^8 * 2^8 * 2^8  =  2^32  ~  4 billion addresses

The problem: there are roughly 100 billion to 1 trillion devices on the internet, but IPv4 offers only ~4 billion addresses. That's nowhere near enough — which is why we also have static vs dynamic IPs (some machines keep a fixed address; most devices borrow one temporarily) and, ultimately, a bigger address space.

IPv6 uses 128 bits, giving 2¹²⁸ ≈ 256 billion billion billion billion possibilities — effectively unlimited. Static IPs stay the same over time (useful for servers you must always reach at the same address); dynamic IPs are assigned on the fly and can change (typical for home/phone devices).

3 Storing data: sharding & partitioning

Why not just one server?

Q: Can we store all the data on 1 server? No. We added more machines in the first place because we were running out of resources — disk space, CPU, memory. One server can't hold it all.

Q: Should we split the data randomly? No — then how would we retrieve it? Data storage has to follow some logic that can be repeated. At any moment we must be able to figure out which data lives on which server.

Two kinds of partitioning

"Splitting data" has two flavors, and each can happen within a database or across servers.

The sharding key

Sharding is always based on some value — the sharding key. The key is what decides which shard (server) a piece of data lives on. (How to choose a good sharding key is a topic for a later lecture.)

4 Routing = sharding, and what makes a good algorithm

Here's the insight. If we route based on user_id, then sharding automatically happens based on user_id too. Why? Because if Sanjana's requests are always routed to server A, then only server A ever sees (and therefore stores) Sanjana's data — servers B and C never received her requests in the first place.

Where routing lives

The routing algorithm runs inside the load balancers. It's how the LB decides which request goes to which server.

What makes a routing algorithm "good"?

A good routing algorithm should have these characteristics:

• Fast — computationally easy to decide which request goes to which server.
• Equal distribution — divides the load (data & requests) equally across all servers.
• Freely add / remove servers — servers are unreliable and crash (count goes down), and we scale out by adding more (count goes up). The algorithm must cope with both.
• Minimal data movement — when the number of servers changes, the amount of data that has to move should be minimal.
• Deterministic without exchanging information — we have multiple load balancers, and they must all stay "in sync," forwarding the same type of request (say Sanjana's) to the same server. Otherwise Sanjana's data ends up scattered everywhere. Crucially, they must achieve this without constantly communicating — per-request chatter between LBs would be far too much overhead.

5 Load balancing algorithms

Once the LB has a list of healthy servers, it needs a rule to pick one for each request. Here are the classic algorithms, from simplest to smartest.

Round Robin

Round Robin just cycles through the servers in order: request 1 → server A, request 2 → server B, request 3 → server C, request 4 → back to A, and so on. Simple, fair, and needs no extra information. Its weakness: it assumes every server and every request is equal — which isn't always true. (When applied to data routing via a modulo trick, it has a bigger flaw we'll dissect in Topic 6.)

Weighted Round Robin

Weighted Round Robin is Round Robin with a "strength" number per server. A beefier server gets a higher weight and therefore more requests. If A has weight 3 and B has weight 1, A receives three requests for every one B receives. Great when your servers aren't all the same size.

# Python: Round Robin and Weighted Round Robin balancers
from itertools import cycle


class RoundRobinBalancer:
    """Cycle through servers in order: A, B, C, A, B, C, ..."""
    def __init__(self, servers):
        self.servers = list(servers)
        self._i = 0

    def next_server(self):
        server = self.servers[self._i]
        self._i = (self._i + 1) % len(self.servers)
        return server


class WeightedRoundRobinBalancer:
    """A=3, B=1 -> A, A, A, B, A, A, A, B, ... (expanded by weight)."""
    def __init__(self, weighted):   # weighted = [(name, weight), ...]
        sequence = []
        for name, weight in weighted:
            sequence.extend([name] * weight)
        self._cycle = cycle(sequence)

    def next_server(self):
        return next(self._cycle)


if __name__ == "__main__":
    rr = RoundRobinBalancer(["A", "B", "C"])
    print("RR:  ", [rr.next_server() for _ in range(6)])
    # RR:   ['A', 'B', 'C', 'A', 'B', 'C']

    wrr = WeightedRoundRobinBalancer([("A", 3), ("B", 1)])
    print("WRR: ", [wrr.next_server() for _ in range(8)])
    # WRR:  ['A', 'A', 'A', 'B', 'A', 'A', 'A', 'B']

// C++: Round Robin and Weighted Round Robin balancers
#include <iostream>
#include <string>
#include <vector>

class RoundRobinBalancer {
    std::vector<std::string> servers_;
    size_t i_ = 0;
public:
    explicit RoundRobinBalancer(std::vector<std::string> servers)
        : servers_(std::move(servers)) {}

    std::string next_server() {
        std::string s = servers_[i_];
        i_ = (i_ + 1) % servers_.size();
        return s;
    }
};

class WeightedRoundRobinBalancer {
    std::vector<std::string> sequence_;   // expanded by weight
    size_t i_ = 0;
public:
    // weighted = {{name, weight}, ...}
    explicit WeightedRoundRobinBalancer(
            const std::vector<std::pair<std::string, int>>& weighted) {
        for (const auto& [name, weight] : weighted)
            for (int n = 0; n < weight; ++n) sequence_.push_back(name);
    }

    std::string next_server() {
        std::string s = sequence_[i_];
        i_ = (i_ + 1) % sequence_.size();
        return s;
    }
};

int main() {
    RoundRobinBalancer rr({"A", "B", "C"});
    std::cout << "RR:  ";
    for (int n = 0; n < 6; ++n) std::cout << rr.next_server() << " ";
    std::cout << "\n";                       // RR:  A B C A B C

    WeightedRoundRobinBalancer wrr({{"A", 3}, {"B", 1}});
    std::cout << "WRR: ";
    for (int n = 0; n < 8; ++n) std::cout << wrr.next_server() << " ";
    std::cout << "\n";                       // WRR: A A A B A A A B
}

// Java: Round Robin and Weighted Round Robin balancers
import java.util.ArrayList;
import java.util.List;
import java.util.Map;

class RoundRobinBalancer {
    private final List<String> servers;
    private int i = 0;

    RoundRobinBalancer(List<String> servers) {
        this.servers = new ArrayList<>(servers);
    }

    String nextServer() {
        String s = servers.get(i);
        i = (i + 1) % servers.size();
        return s;
    }
}

class WeightedRoundRobinBalancer {
    private final List<String> sequence = new ArrayList<>();  // expanded by weight
    private int i = 0;

    WeightedRoundRobinBalancer(List<Map.Entry<String, Integer>> weighted) {
        for (Map.Entry<String, Integer> e : weighted)
            for (int n = 0; n < e.getValue(); n++) sequence.add(e.getKey());
    }

    String nextServer() {
        String s = sequence.get(i);
        i = (i + 1) % sequence.size();
        return s;
    }
}

public class Balancers {
    public static void main(String[] args) {
        RoundRobinBalancer rr = new RoundRobinBalancer(List.of("A", "B", "C"));
        System.out.print("RR:  ");
        for (int n = 0; n < 6; n++) System.out.print(rr.nextServer() + " ");
        System.out.println();                  // RR:  A B C A B C

        WeightedRoundRobinBalancer wrr = new WeightedRoundRobinBalancer(
            List.of(Map.entry("A", 3), Map.entry("B", 1)));
        System.out.print("WRR: ");
        for (int n = 0; n < 8; n++) System.out.print(wrr.nextServer() + " ");
        System.out.println();                  // WRR: A A A B A A A B
    }
}

Least Connections

Least Connections sends each new request to the server currently handling the fewest active connections. This adapts to reality: if one server is stuck on a few slow, long-lived requests, it stops getting new ones. Ideal when requests vary a lot in how long they take.

Least Response Time

Least Response Time goes further: it picks the server with the lowest combination of active connections and fastest recent response time. It's the most "performance-aware" of the common algorithms — it actively favors the server that is currently quickest to answer.

IP hash / hash-based

IP hash (a form of hash-based balancing) computes a hash of the client's IP address (or some other key) and uses it to pick a server. The key property: the same client always lands on the same server. This gives us session stickiness — useful when a server keeps some per-user state in memory. (Spoiler: this is the bridge to consistent hashing in the next topics.)

Random

Random simply picks a server at random. With enough requests, the math of large numbers spreads load fairly evenly. A popular refinement is "power of two choices": pick two servers at random and send the request to whichever has fewer connections — surprisingly close to optimal, with almost no bookkeeping.

Comparison — which fits when

6 Naive routing schemes & their problems

Let's test simple routing ideas against our checklist from Topic 4 (fast, equal, free add/remove, minimal data movement, no syncing). Each one fails somewhere — which is exactly why consistent hashing exists.

Attempt 1 — Round Robin via modulo

The simplest routing is a % (modulo) based technique: send each request to the "next" server, computed as key % N.

server_list = ["10.11.6.12", "10.11.5.17", ...]

fn handle_request(request):
    key = request.user_id
    N = len(server_list)
    server_id = key % N
    server = server_list[server_id]
    forward_request(request, server)

With server_list = [A, B, C, D] and user_ids 0…100, the initial distribution (user_id % 4) is tidy:

Now server B crashes, so N = 3 and everything becomes user_id % 3:

Yes, users (1, 5, 9, …) who were on the crashed server B obviously have to move — that's expected (their data is migrated; how is a separate topic the class jokingly tags "Son Pari"). But other users' data should not need to move, since their servers are still fine. Is that the case? No! Pretty much all the data gets shuffled around, because changing N changes user_id % N for almost everyone. Adding servers has the same effect.

Attempt 2 — Bucketing

Bucketing assigns user_ids to servers in fixed ranges:

If server B crashes, the ranges have to be recomputed across the remaining three servers — moving a lot of data:

And when more users sign up, there's a second problem: we already decided the buckets, so there's no room for new users in existing servers. It's impossible to add new users without first buying more servers.

Attempt 3 — Mapping table

What if the LB just keeps a hashmap from user_id to server_id?

server_list = ["10.11.6.12", "10.11.5.17", ...]
mapping = {
    sanjana: A,
    prem:    B,
    bathula: A,
    pallavi: C,
    venkat:  B,
    ...
}

fn handle_request(request):
    key = request.user_name
    server = mapping[key]
    forward_request(request, server)

Handling crashes and new users is straightforward — only the affected entries change:

fn handle_server_crash(crashed_server):
    for user, server in mapping:
        if server == crashed_server:
            # assign a new server to this user
            new_server = get_random_server()
            mapping[user] = new_server
            son_pari_please_migrate(user, crashed_server, new_server)

fn handle_new_user(user):
    server = get_random_server()
    mapping[user] = server

This is much better on data movement: users who were on the crashed server get moved (desired), and users whose servers are still running do not get moved. But there's a fatal catch.

The deeper flaw behind modulo hashing

When the goal is to spread data (e.g. which cache server stores which key), the modulo trick hash(key) % N is the same Attempt 1 in disguise:

# N = number of servers
server_index = hash(key) % N

Here hash(key) turns the key into a big number, and % N squashes it into 0 … N-1 — a valid server index. Looks perfect, until N changes.

7 Hash functions & the hash ring

What is a function?

A function is a deterministic mapping from inputs to outputs. No matter how many times you call it with the same input, you get the same output:

fn add(a, b):
    return a + b

add(2, 3)  => 5
add(2, 3)  => 5
add(2, 3)  => 5   # always the same for the same input

Compare that to a procedure (an "impure" function) that has side effects — it can return different values for the same input because it reads or writes external state:

state = 0
proc add(a, b):
    state = b
    return a + b + state
# Not always the same output — it has side effects.

What is a hash function?

A hash function is a "digest" function: it takes anything as input but returns values within a fixed range. Some toy examples that all output a value in 0 … 99 (or some fixed range):

fn hash_1(data):
    return (sum of ascii values of chars of data) % 100
fn hash_2(data):
    return (sum of squares of ascii values of chars of data) % 799
fn hash_3(data):
    return (multiply even and odd numbers in the data) % 1337

# No matter the input, the output is always within the fixed range.

The hash ring

The hash ring is simply the output space of a given hash function, drawn as a circle. If your hash outputs values in 0 … (2⁶⁴ − 1), the ring runs from 0 around to 2⁶⁴−1 and wraps back to 0.

Placing users & servers on the ring

• Use 1 hash function hash_0 for hashing the users.
• Use k hash functions hash_1 … hash_k for hashing the servers — a typical value of k is 32 or 64. (Each server is placed at k spots on the ring; this is the "virtual nodes" idea of Topic 8.)

These hash functions are set up while the LB is being coded/configured. All LBs for a system share the exact same set of hash functions, and all (k+1) functions have the same output space (say 0 … 2⁶⁴ − 1).

8 Consistent hashing

Consistent hashing solves the rehashing problem with one clever change: instead of hashing keys directly into "server slots," we hash both servers and keys onto the same circle, called the hash ring.

The algorithm

1. For each server, hash it using all the hash functions hash_1 … hash_k and place the server at those spots on the ring.
2. When a request arrives, hash the user_id using hash_0 and place the user on the ring.
3. Forward the request to the first server clockwise from the user's position.

        0 / 360°  (top of the ring)
                  │
        S_A ●─────┼─────● S_B
          ╱       │       ╲
         ╱   k1   │   k2    ╲     keys walk CLOCKWISE → first server
        │    ↓    │    ↓     │
        │   (→A)  │   (→B)   │
         ╲        │        ╱
          ╲   k3  │       ╱
        S_C ●─────┼─────● (back to S_A)
                  │
        k1 → next server clockwise = A
        k2 → next server clockwise = B
        k3 → next server clockwise = C

A working implementation

Here is a full implementation in three languages. The ring is a sorted structure of (position, server) points (each server placed at many virtual node spots), and get_node is a binary search for the first server clockwise of the key, wrapping around the end of the ring. The demo adds a 4th server and shows that only a small fraction of keys move — the rest stay mapped to their original server.

# Python: consistent-hash ring with virtual nodes + binary search
import bisect
import hashlib

RING_SIZE = 1 << 32


def _hash(label):
    digest = hashlib.md5(label.encode()).hexdigest()
    return int(digest, 16) % RING_SIZE


class ConsistentHashRing:
    def __init__(self, vnodes=150):
        self.vnodes = vnodes
        self._positions = []          # sorted ring positions
        self._owner = {}              # position -> server name

    def add_node(self, name):
        for i in range(self.vnodes):
            pos = _hash(f"{name}#{i}")
            if pos not in self._owner:
                bisect.insort(self._positions, pos)
                self._owner[pos] = name

    def remove_node(self, name):
        for i in range(self.vnodes):
            pos = _hash(f"{name}#{i}")
            if self._owner.get(pos) == name:
                del self._owner[pos]
                idx = bisect.bisect_left(self._positions, pos)
                self._positions.pop(idx)

    def get_node(self, key):
        if not self._positions:
            return None
        pos = _hash(key)
        # first ring position clockwise of the key (wrap to 0)
        idx = bisect.bisect_right(self._positions, pos) % len(self._positions)
        return self._owner[self._positions[idx]]


if __name__ == "__main__":
    ring = ConsistentHashRing()
    for s in ["A", "B", "C"]:
        ring.add_node(s)

    keys = [f"user-{i}" for i in range(10)]
    before = {k: ring.get_node(k) for k in keys}

    ring.add_node("D")                 # add a 4th server
    after = {k: ring.get_node(k) for k in keys}

    moved = [k for k in keys if before[k] != after[k]]
    print("moved:", moved)         # only a small fraction remap to D
    print("stayed:", [k for k in keys if k not in moved])

// C++: consistent-hash ring with virtual nodes + binary search
#include <cstdint>
#include <functional>
#include <iostream>
#include <map>
#include <string>
#include <vector>

class ConsistentHashRing {
    int vnodes_;
    std::map<uint64_t, std::string> ring_;   // sorted: position -> server

    static uint64_t hashLabel(const std::string& label) {
        return std::hash<std::string>{}(label);
    }
public:
    explicit ConsistentHashRing(int vnodes = 150) : vnodes_(vnodes) {}

    void add_node(const std::string& name) {
        for (int i = 0; i < vnodes_; ++i)
            ring_[hashLabel(name + "#" + std::to_string(i))] = name;
    }

    void remove_node(const std::string& name) {
        for (int i = 0; i < vnodes_; ++i) {
            auto it = ring_.find(hashLabel(name + "#" + std::to_string(i)));
            if (it != ring_.end() && it->second == name) ring_.erase(it);
        }
    }

    std::string get_node(const std::string& key) const {
        if (ring_.empty()) return {};
        // first position clockwise of the key (wrap to begin)
        auto it = ring_.upper_bound(hashLabel(key));
        if (it == ring_.end()) it = ring_.begin();
        return it->second;
    }
};

int main() {
    ConsistentHashRing ring;
    for (const std::string& s : {"A", "B", "C"}) ring.add_node(s);

    std::vector<std::string> keys;
    for (int i = 0; i < 10; ++i) keys.push_back("user-" + std::to_string(i));

    std::vector<std::string> before;
    for (const auto& k : keys) before.push_back(ring.get_node(k));

    ring.add_node("D");                  // add a 4th server

    std::cout << "moved:";
    for (size_t i = 0; i < keys.size(); ++i)
        if (ring.get_node(keys[i]) != before[i]) std::cout << " " << keys[i];
    std::cout << "\n";                       // only a small fraction remap to D
}

// Java: consistent-hash ring with virtual nodes + binary search
import java.nio.charset.StandardCharsets;
import java.security.MessageDigest;
import java.util.ArrayList;
import java.util.List;
import java.util.SortedMap;
import java.util.TreeMap;

class ConsistentHashRing {
    private final int vnodes;
    private final SortedMap<Long, String> ring = new TreeMap<>();

    ConsistentHashRing(int vnodes) { this.vnodes = vnodes; }
    ConsistentHashRing() { this(150); }

    private static long hash(String label) {
        try {
            byte[] d = MessageDigest.getInstance("MD5")
                .digest(label.getBytes(StandardCharsets.UTF_8));
            long h = 0;
            for (int i = 0; i < 8; i++) h = (h << 8) | (d[i] & 0xff);
            return h >>> 32;          // 32-bit ring position
        } catch (Exception e) { throw new RuntimeException(e); }
    }

    void addNode(String name) {
        for (int i = 0; i < vnodes; i++) ring.put(hash(name + "#" + i), name);
    }

    void removeNode(String name) {
        for (int i = 0; i < vnodes; i++) {
            long pos = hash(name + "#" + i);
            if (name.equals(ring.get(pos))) ring.remove(pos);
        }
    }

    String getNode(String key) {
        if (ring.isEmpty()) return null;
        // first position clockwise of the key (wrap to first)
        SortedMap<Long, String> tail = ring.tailMap(hash(key) + 1);
        Long pos = tail.isEmpty() ? ring.firstKey() : tail.firstKey();
        return ring.get(pos);
    }
}

public class Ring {
    public static void main(String[] args) {
        ConsistentHashRing ring = new ConsistentHashRing();
        for (String s : List.of("A", "B", "C")) ring.addNode(s);

        List<String> keys = new ArrayList<>();
        for (int i = 0; i < 10; i++) keys.add("user-" + i);

        List<String> before = new ArrayList<>();
        for (String k : keys) before.add(ring.getNode(k));

        ring.addNode("D");                 // add a 4th server

        System.out.print("moved:");
        for (int i = 0; i < keys.size(); i++)
            if (!ring.getNode(keys.get(i)).equals(before.get(i)))
                System.out.print(" " + keys.get(i));
        System.out.println();              // only a small fraction remap to D
    }
}

Checking it against the requirements

The payoff: only K/N keys move

Here's the magic. When a new server S_D joins, it lands at some single spot on the ring. The only keys that change homes are the ones sitting in the arc between S_D and the previous server clockwise-before it — those keys now bump into S_D first. Every other key on the ring is completely unaffected.

On average, a single node owns about 1/N of the ring, so adding or removing a node only moves about K/N keys (where K = total keys, N = number of servers) instead of nearly all of them. Removing a server is the mirror image: its keys simply flow clockwise to the next server, and nobody else moves.

A simpler pseudocode view of the ring

# A sorted list of (position, server) points around the ring.
ring = sorted_map()   # keyed by position 0 .. 2^32-1

def add_server(name):
    pos = hash(name) % RING_SIZE
    ring[pos] = name

def remove_server(name):
    pos = hash(name) % RING_SIZE
    del ring[pos]

def get_server(key):
    pos = hash(key) % RING_SIZE
    # walk clockwise: first server position >= pos
    for p in ring.keys_sorted():
        if p >= pos:
            return ring[p]
    # wrapped past the end → take the first server (smallest pos)
    return ring.first_value()

Virtual nodes — fixing uneven balance

One catch: if you only place one point per server, the ring can be lumpy. By bad luck, two servers might land close together, leaving a huge arc owned by a third server — which then gets far more keys. The fix is virtual nodes (also called vnodes): place each physical server at many points around the ring (e.g. A#1, A#2, … A#150), each hashed separately. This is exactly the role of the k server hash functions (k ≈ 32–64) from Topic 7.

• With ~100–200 vnodes per server, the points interleave finely, so each physical server owns many small arcs that add up to a fair, even share.
• Bonus: when a server dies, its load spreads across many other servers (one per vnode arc), rather than dumping entirely onto a single unlucky neighbor.

def add_server(name, vnodes=150):
    for i in range(vnodes):
        pos = hash(f"{name}#{i}") % RING_SIZE
        ring[pos] = name   # many points, all mapping back to 'name'

9 Where consistent hashing is used

Consistent hashing is one of the most reused ideas in distributed systems. It appears wherever data must be sharded (split) across many nodes that can come and go. Here's where you'll meet it in the real world.

★ Putting it all together

This session was all about spreading work and data across many machines — gracefully. Here's the one-paragraph story tying the topics together:

Quick self-check

📚 References & Further Reading

Class material

• 📄 Original class notes / handout (Google Doc) — open the shared class material for this session.
• Class handout: "[SST-2028] Load Balancing & Consistent Hashing".
• How to configure load balancing — the class setup doc.
• Arpit Bhayani: Consistent Hashing — deep dive matching the class's ring implementation.

Tutorials & cloud docs

• AviNetworks: What is load balancing? — friendly intro tutorial.
• AWS: Getting started with Elastic Load Balancing (ELB).
• NGINX: HTTP Load Balancing guide — round-robin, least-connections, IP-hash and health checks in practice.

Hash functions & consistent hashing

• Wikipedia: Hash function — definitions & properties.
• Wikipedia: Cryptographic hash function — extra guarantees.
• Wikipedia: Universal hashing — families of hashes.
• Wikipedia: K-independent hashing.
• Karger et al.: Consistent Hashing and Random Trees — the original 1997 paper that introduced consistent hashing.
• The System Design Primer — clear sections on load balancers and balancing strategies.