Hi David, On Wed, Sep 30, 2026 at 04:37:25PM -0700, David Birdsong wrote: > 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.
To be honest, I'm totally ignorant of rendezvous hashing, and I have not yet understood from your description above what problem it tries to solve better. I think that you have a use case in mind, it would be great if you could illustrate how such a workload is currently handled now versus how it would be handled with your approach. Aside this, if you need to extend lb_ops, do not restrict yourself! You may need to add info to the struct proxy (be more careful about what can increase its size), and the server struct (be even more careful there), but I'm saying this as indications, just do not block yourself while you are experimenting. Willy
