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 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.
