Plain consistent hashing solves the reshuffle problem when nodes join or leave, but it has a nasty failure mode: load imbalance. Even with virtual nodes, one shard can end up with 2-3x the traffic of its neighbors because keys aren't uniformly popular. A single celebrity user, a viral video, or a hot tenant can melt one node while the rest of the ring idles.

Consistent Hashing with Bounded Loads (CHWBL), introduced by Google in 2016, fixes this with one rule: no node may exceed a defined fraction of the average load. When hashing a key lands on a node that's already at capacity, you walk the ring clockwise to the next available node.

The bound is expressed as (1 + ε) × average_load, where ε is a small constant like 0.25. If the average node handles 1000 requests/sec, no node may exceed 1250 requests/sec.

Real-world example: Vimeo uses CHWBL in their load balancer for video encoding. Without it, a single popular upload could pin one encoder while others sat idle. With ε=0.25, they get 80% of consistent hashing's cache-locality benefits (repeat keys usually land on the same node) while capping worst-case skew. Google Cloud's HTTP(S) Load Balancer offers this as a built-in option.

The math is elegantly simple:

• N nodes, total load L → average = L/N
• Cap per node = ⌈(1 + ε) × L/N⌉
• With ε=0, you get perfect balance but zero placement stability (pure round-robin)
• With ε=∞, you get plain consistent hashing with all its skew
• ε=0.25 is the sweet spot for most production systems

Rule of thumb: The probability a key lands on its "natural" node is roughly 1 - ε/(1+ε). At ε=0.25, that's 80% cache-hit locality. At ε=1.0, it drops to 50% — you've mostly given up the hashing benefits.

Watch out for:

• Load counter accuracy — you need real-time (or near real-time) load per node. Stale counters cause thundering-herd overshoots.
• Node removal — when a node fails, its load redistributes to the walked-to alternates. Make sure your ε buffer can absorb this without cascading.
• Definition of "load" — connections, in-flight requests, and CPU are different signals. Pick one and be consistent.
• Non-uniform request cost — CHWBL bounds request count, not work. If your requests vary wildly in cost, use weighted load instead.

CHWBL is the pragmatic middle ground: you get placement stability for cache locality, plus a hard ceiling on how badly one node can be punished. It's why modern service meshes (Envoy, Linkerd) ship it as a first-class load-balancing option.