Rendezvous hashing picks a node per key by scoring every node and taking the max. Weighted rendezvous multiplies scores by capacity, so beefier boxes get more keys. But pure weighted rendezvous has the same failure mode as pure consistent hashing: hot keys ignore capacity. If a viral video's key hashes to your smallest node, that node melts regardless of weight. Bounded loads fixes this by capping each node at a fraction over its fair share.

The algorithm: for each key, score every node as weight_i * -1/ln(hash(node_i, key)), then sort nodes by score descending. Walk the sorted list and assign the key to the first node whose current load is below (1 + ε) * capacity_share. The ε parameter (typically 0.1 to 0.25) is your overflow budget — how much a node can exceed its fair share before keys spill to the next preference.

Real-world example: Discord's message routing across guild shards. Some guilds are 10,000x more active than others, and shard machines come in three tiers (16, 32, 64 core). Pure weighted rendezvous would route a viral guild to whichever machine won the hash lottery. With bounded loads at ε=0.2, when a guild's assigned shard hits 120% of its capacity share, new sessions for that guild spill to the next-ranked shard. The guild stays sticky under normal load (rendezvous determinism) but overflows gracefully during spikes.

The math: With N keys and total capacity C, each node's fair share is (weight_i / total_weight) * N. The overflow cap is (1 + ε) * fair_share. Smaller ε means better balance but more reassignments during churn; larger ε means stability at the cost of hot spots. Rule of thumb: ε ≈ 1/√(fair_share) keeps expected overflow rate under 5% for uniform workloads.

What breaks it:

• Stale load counters. If nodes report load every 30s, bursts within the window bypass the cap entirely. Use per-request local counters, not periodic snapshots.
• Cascading overflow. If node A is full and spills to B, and B is near capacity, B spills to C. Under load spikes this becomes a stampede. Add jitter to overflow ordering.
• Weight changes mid-flight. Scaling a node's weight up during traffic invalidates the sort order for in-flight keys. Recompute lazily on next lookup, don't rebalance eagerly.

Bounded loads adds O(log N) overhead per lookup versus pure rendezvous, but survives the workloads that make pure hashing embarrassing.