Rendezvous hashing is simple to understand. I'm surprised that the article didn't mention the skeleton-based variant which provides O(log N) lookup (same as con

Rendezvous hashing is simple to understand. I'm surprised that the article didn't mention the skeleton-based variant which provides O(log N) lookup (same as consistent hashing). Based on my experience implementing the skeleton-based variant, it does add a fair bit of additional complexity compared to plain rendez-vous hashing but IMO, it's still much simpler to implement than ring-based consistent hashing (with optimizations). The main downside of skeleton-based rendez-vous hashing compared to ring-based consistent hashing is that when a server (aka 'site') leaves the cluster, you need to iterate over all the keys in order to do the re-mapping. Skeleton-based rendez-vous hashing minimizes the number of keys which will need to be moved when a server leaves the cluster (at least as well as consistent hashing does), but you still need to go through every key in order to check whether or not it has moved; there are no shortcuts to check only a subset of keys. With consistent hashing, if a server leaves the cluster, you only need to check keys which fall within the affected 'sector' of the ring so you can completely ignore all the other keys. That said, I find that skeleton-based rendez-vous hashing is simple to implement and maintain, it's fast and it spreads keys pretty evenly (especially in the long run). Consistent hashing can become uneven over time if multiple nearby severs/sites leave the ring; that's why some solutions make use of 'virtual sites/servers' which never leave the ring (but this adds complexity and overhead).