I've done some background work to see how my idea would thread through. On Sat, Sep 26, 2026 at 2:14 PM David Birdsong <[email protected]> wrote: > > It's me again asking about hashing again almost 20 years later. I'm > curious how this new feature would be received: a new hashing type, > rendezvous hashing (aka HRW, "highest random weight") alongside > map-based and consistent. > > We want a way to bound a given tenant's traffic to a fixed, small > subset of backend servers, irrespective of what fails or scales in the > backend as a means for containing the tenant. > > Concretely: with N servers and a per-tenant hash key, rank the > configured server list independently of health, and let a tenant only > ever land on the top Y of that ranking. We would allow health/load to > filter within that fixed set, but must never expand outside it. So > this would pair well with hash-balance-factor settings. The rough
Health and load would be enforced via a mode of selection scoped to the fixed candidate set itself (e.g. picking the least-loaded of the top Y, or walking a decayed priority order), rather than the existing hash-balance-factor mechanism, whose fairness quota is computed against the whole backend and doesn't have a coherent meaning against a small per-tenant subset. So I'm leaning heavily towards dropping the use of hash-balance-factor. > shape I have in mind is a new directive, hash-candidates <count>, > valid only alongside hash-type rendezvous, where <count> sets Y: how > many top-ranked servers from a given key's fixed candidate set. > > Consistent hashing doesn't give this property at any virtual node > count. Its fallback path (walking the ring past an unhealthy node) is > health dependent by construction, so there's no fixed, addressable > candidate set per key to point to and say "this tenant can never leave > this set" which is why I think this is worth a new algorithm rather > than tweaks to the existing one. > > Impact-wise, this would not be a performance win over chash. One would > only reach for this when they want the containment vs request > distribution: > - request path: O(N) per lookup (score every configured server), > versus chash's O(log M) tree descent. chash wins here as N grows. > Again only use rendezvous for its containment property. > - server add/remove: O(1), versus chash's O(m_s) removal / O(m_s log > M) insertion (i.e. no tree to touch at all). > > We would trade slower per-request lookup for zero membership-update > cost and a fixed, enumerable per-tenant candidate set. I'd like to get > some feedback on whether that tradeoff is worth a new lb_ops module > and a widened hash-type field. > > I'm happy to follow up with more details on complexity and a rough > sketch design (candidate-set directive, backup-server model options, > retry/redispatch interaction) but wanted to gauge interest and > receptiveness to this new feature. If nobody has any feedback for now, I'll just get a patch going and try it out on our side.
