Rendezvous Hashing, o HRW Hashing, es un algoritmo de hashing distribuido que permite a un conjunto de clientes ponerse de acuerdo sobre qué servidor de un conjunto dinámico de servidores es responsable de una clave particular. A diferencia de Consistent Hashing, donde los nodos y las claves se mapean a un anillo, Rendezvous Hashing opera asignando un 'peso' a cada servidor para una clave dada. Para una clave 'k' y un conjunto de servidores 'S = {s1, s2, ..., sn}', cada servidor 'si' calcula un valor de hash 'h(k, si)'. El cliente selecciona el servidor 'sj' para el cual 'h(k, sj)' es el valor más alto. La función de hash 'h' debe ser independiente y generar valores distribuidos uniformemente. La principal ventaja es su simplicidad y la garantía de que todos los clientes, dado el mismo conjunto de servidores, seleccionarán el mismo servidor para una clave.
Rendezvous Hashing se utiliza en varios sistemas distribuidos donde la coordinación descentralizada y la baja reasignación son cruciales. Un ejemplo notable es su uso en el protocolo de descubrimiento de servicios de Apache Cassandra para la selección de nodos. También se emplea en sistemas de caché distribuidos y balanceadores de carga para distribuir solicitudes de manera eficiente entre un conjunto de servidores. Otro ejemplo es su aplicación en sistemas de almacenamiento de objetos, donde se utiliza para determinar qué nodo almacena una réplica de un objeto, asegurando una distribución uniforme y una fácil escalabilidad horizontal.
Para un arquitecto, Rendezvous Hashing es importante por su capacidad para simplificar la lógica de distribución de datos y solicitudes en entornos dinámicos. Ofrece una excelente propiedad de 'minimal disruption' (mínima interrupción): cuando un servidor se añade o se elimina, solo las claves que estaban mapeadas a ese servidor (o que ahora se mapearán a él) se ven afectadas, a diferencia de un hashing modular simple donde casi todas las claves podrían reasignarse. Esto reduce significativamente el tráfico de rebalanceo y la complejidad operativa. Sin embargo, un trade-off es que puede requerir que los clientes conozcan la lista completa de servidores activos para realizar el cálculo, lo que puede ser un desafío en sistemas con un gran número de nodos o alta volatilidad. Su simplicidad de implementación y su rendimiento predecible lo hacen una opción robusta para arquitecturas que priorizan la resiliencia y la escalabilidad horizontal.