¿Cuáles son los principales algoritmos de balanceo de carga — round robin, least connections, hashing consistente — y cuándo encaja cada uno?

#Por qué importa el algoritmo

El trabajo de un balanceador de carga suena simple — elegir un backend para cada petición entrante — pero el algoritmo detrás de esa elección determina si tus backends se mantienen equilibrados, si una petición lenta en un servidor arrastra a los demás, y si una capa que protege una caché conserva su hit rate cuando añades o quitas un nodo. Los entrevistadores preguntan esto para ver si sabes que "balanceo de carga" no es un solo algoritmo — es una familia de contrapartidas, y elegir mal para la forma de tráfico que tienes enfrente causa incidentes reales.

#Round robin y round robin ponderado

Round robin envía la petición 1 al servidor A, la 2 al B, la 3 al C, y vuelve a A — recorriendo el pool en orden. No requiere ningún estado sobre los backends más allá de la lista del pool, lo que lo hace barato y predecible. El round robin ponderado extiende esto dando a cada servidor un peso proporcional a su capacidad, de modo que un servidor con peso 3 recibe tres peticiones por cada una que recibe un servidor con peso 1 — útil cuando tu flota es heterogénea (una mezcla de tamaños de instancia durante una migración, por ejemplo).

El punto ciego de round robin es que asume que cada petición cuesta más o menos lo mismo. No rastrea qué tan ocupado está realmente un servidor, así que si una petición resulta ser costosa (la generación de un reporte grande, una llamada lenta a un servicio downstream), round robin igual mandará la siguiente petición a ese mismo servidor sobrecargado.

#Least connections (menor número de conexiones)

Least connections enruta cada petición nueva al backend que en ese momento tenga menos conexiones abiertas. Esto ataca directamente el punto ciego de round robin: reacciona a la carga real en lugar de asumir un costo uniforme por petición, lo que lo convierte en la mejor opción por defecto para cargas de trabajo con duración variable — conexiones WebSocket de larga duración, streams gRPC, o APIs donde algunos endpoints son mucho más costosos que otros.

Su costo es que el balanceador debe llevar la cuenta de conexiones por backend en tiempo real, un poco de estado y coordinación que round robin no necesita — normalmente trivial para una sola instancia de balanceador, pero algo a tener en cuenta si corres varias instancias de LB que no comparten ese estado.

#IP hash / hashing por origen

IP hash (o hashing por IP de origen) calcula un hash de la IP del cliente y lo usa para elegir consistentemente el mismo backend para ese cliente en cada petición. Esto da afinidad de sesión ("sticky sessions") sin un almacén de sesión compartido — conveniente, pero con desventajas reales: distribuye la carga de forma desigual si las IPs de tus clientes no están distribuidas uniformemente (un gateway NAT grande, un proxy corporativo o el pool de IPs compartido de un operador móvil pueden concentrar tráfico enorme en un solo bucket del hash), y se rompe en cuanto la IP de un cliente cambia a mitad de sesión (un handoff de red móvil) o se retira un servidor del pool, ya que quitar un nodo reordena a qué bucket hashea cada uno de los demás clientes.

#Hashing consistente

El hashing consistente resuelve exactamente ese problema de reordenamiento. En lugar de mapear con `hash(key) mod N` (lo cual remapea casi todas las llaves cuando N cambia), coloca tanto a los servidores como a las llaves en un anillo de hash, y una llave la sirve el siguiente servidor en sentido horario desde su posición en el anillo. Añadir o quitar un servidor solo reordena las llaves entre ese servidor y su vecino en el anillo — se mueven aproximadamente `K/N` llaves en vez de casi todas. Las implementaciones reales añaden nodos virtuales (cada servidor físico obtiene muchos puntos en el anillo) para evitar buckets de tamaño desigual.

Este es el algoritmo al que recurres frente a una capa de backend con estado — una capa de caché, un almacén clave-valor particionado — donde a qué nodo cae una llave importa para la localidad de la caché, no solo para repartir el número de conexiones. Equivocarse con esto en una capa de caché significa que un despliegue rolling que añade o quita un nodo de caché puede provocar una estampida masiva y correlacionada de cache misses contra tu base de datos.

#Configuración real

Ajustar líneas largas
# Round robin (por defecto) con pesos — bueno para una capa de API homogénea y sin estado
upstream api_backend {
    server 10.0.1.10:8080 weight=3;
    server 10.0.1.11:8080 weight=1;
    server 10.0.1.12:8080 backup;
}

# Least connections — bueno cuando el costo de la petición varía mucho (websockets, long polling)
upstream ws_backend {
    least_conn;
    server 10.0.2.10:8080;
    server 10.0.2.11:8080;
    server 10.0.2.12:8080;
}

# Hashing consistente sobre el URI de la petición — bueno para una capa que protege una caché
upstream cache_backend {
    hash $request_uri consistent;
    server 10.0.3.10:11211;
    server 10.0.3.11:11211;
    server 10.0.3.12:11211;
}

server {
    listen 80;

    location /api/ {
        proxy_pass http://api_backend;
    }

    location /ws/ {
        proxy_pass http://ws_backend;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

# La misma intención expresada en HAProxy

backend api_servers
    balance roundrobin
    server web1 10.0.1.10:8080 weight 3 check
    server web2 10.0.1.11:8080 weight 1 check

backend ws_servers
    balance leastconn
    server ws1 10.0.2.10:8080 check
    server ws2 10.0.2.11:8080 check

backend cache_servers
    balance uri
    hash-type consistent
    server cache1 10.0.3.10:11211 check
    server cache2 10.0.3.11:11211 check
    server cache3 10.0.3.12:11211 check

#Haciendo coincidir el algoritmo con el tráfico

🧠 Check your understanding
0/2 · 0/2 answered
1. ¿Por qué quitar un nodo de un anillo de hashing consistente solo remapea aproximadamente K/N llaves, en vez de casi todas como haría un simple hash(key) mod N?
El hashing consistente en realidad no redistribuye ninguna llave al remover un nodoEl hashing consistente usa un espacio de hash más pequeñoLas llaves se ubican en un anillo y solo las que estaban entre el nodo removido y su vecino necesitan moverse, no las que sirven nodos no relacionadosSe apoya en expiración por TTL en vez de remapeo
2. Un balanceador está frente a una API donde un puñado de endpoints generan reportes pesados y tardan de 10 a 20 veces más que el resto, mientras que la mayoría de los backends son por lo demás idénticos. ¿Qué algoritmo maneja mejor esto de fábrica?
Least connectionsRound robinRound robin ponderado con pesos estáticosIP hash