{"schemaVersion":1,"id":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing","url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing","title":"Algoritmos de Balanceo de Carga: Maglev Hashing, Consistent Hashing con Cargas Acotadas y P2C","description":"Análisis de algoritmos modernos de balanceo de carga, Maglev hashing de Google, consistent hashing con cargas acotadas, power of two choices y configuraciones de producción de HAProxy/Envoy.","language":"es","datePublished":"2026-01-30","dateModified":null,"contentFormat":"text/markdown","content":"Infrastructure\n\n# Algoritmos de Balanceo de Carga: Maglev Hashing, Consistent Hashing con Cargas Acotadas y P2C\n\n2026-01-305 min lectura\n\nLucio Durán\nEngineering Manager & AI Solutions Architect\n\nTambién disponible en: [English](<https://lucioduran.com/blog/load-balancing-algorithms-maglev-consistent-hashing>)\n\n## Fundamentos: por qué round-robin falla\n\nRound-robin asume que todos los requests cuestan lo mismo y todos los backends tienen la misma capacidad. Ninguna de las dos cosas es cierta en la práctica.\n\n```python\n# simulation.py - Por qué round-robin falla con latencia variable\nimport random\nimport statistics\nfrom dataclasses import dataclass, field\n\n@dataclass\nclass Backend:\n name: str\n capacity: int\n active: int = 0\n total_served: int = 0\n latencies: list = field(default_factory=list)\n\ndef simulate_round_robin(backends, requests):\n idx = 0\n for _ in range(requests):\n backend = backends[idx % len(backends)]\n latency = random.expovariate(1/50) if random.random() < 0.1 else random.expovariate(1/2)\n backend.active += 1\n backend.total_served += 1\n backend.latencies.append(latency)\n if backend.active > backend.capacity:\n backend.latencies[-1] *= 3\n backend.active = max(0, backend.active - 1)\n idx += 1\n\ndef simulate_least_conn(backends, requests):\n for _ in range(requests):\n backend = min(backends, key=lambda b: b.active)\n latency = random.expovariate(1/50) if random.random() < 0.1 else random.expovariate(1/2)\n backend.active += 1\n backend.total_served += 1\n backend.latencies.append(latency)\n if backend.active > backend.capacity:\n backend.latencies[-1] *= 3\n backend.active = max(0, backend.active - 1)\n\nrr_backends = [Backend(f\"rr-{i}\", capacity=50) for i in range(5)]\nlc_backends = [Backend(f\"lc-{i}\", capacity=50) for i in range(5)]\n\nsimulate_round_robin(rr_backends, 10000)\nsimulate_least_conn(lc_backends, 10000)\n\n# Output típico:\n# Round Robin: p99 rango = 142.3ms - 148.7ms (todos los backends sufren igual)\n# Least Conn: p99 rango = 4.8ms - 7.2ms (requests lentos concentrados)\n```\n\n## Consistent Hashing: El Problema de Localidad de Cache\n\nConsistent hashing mapea tanto keys como servidores a un anillo. Una key es servida por el siguiente servidor en sentido horario. Cuando se agrega o elimina un servidor, solo las keys que estaban asignadas a él se remapean.\n\nEl problema: hot keys. Si el 30% de tu tráfico pega en una sola cache key, consistent hashing manda el 30% del tráfico a un solo backend.\n\n### Consistent Hashing con Cargas Acotadas\n\nEl paper de Google de 2017 introdujo un fix: poner un tope a la carga máxima de cualquier backend. Cuando un backend alcanza su límite, el request se derrama al siguiente nodo del anillo.\n\n```go\nfunc (ch *BoundedConsistentHash) GetNode(key string, loads map[string]int, avgLoad float64, epsilon float64) string {\n ch.mu.RLock()\n defer ch.mu.RUnlock()\n\n maxLoad := int(avgLoad * (1 + epsilon))\n h := ch.hash(key)\n idx := sort.Search(len(ch.ring), func(i int) bool { return ch.ring[i] >= h })\n\n for i := 0; i < len(ch.ring); i++ {\n nodeIdx := (idx + i) % len(ch.ring)\n node := ch.nodes[ch.ring[nodeIdx]]\n if loads[node] < maxLoad {\n return node\n }\n }\n return ch.nodes[ch.ring[idx]]\n}\n```\n\nCon ` epsilon = 0.25 `, ningún backend recibe más del 125% de la carga promedio.\n\n## Maglev Hashing: El Algoritmo de Producción de Google\n\nMaglev genera una tabla de lookup donde cada entrada mapea a un backend. La construcción de la tabla asegura mínima disrupción cuando los backends cambian.\n\n```python\n# maglev.py\ndef maglev_table(backends: list[str], table_size: int = 65537) -> list[int]:\n n = len(backends)\n permutations = []\n for backend in backends:\n h1 = hash(backend + \"_offset\") % table_size\n h2 = (hash(backend + \"_skip\") % (table_size - 1)) + 1\n perm = [(h1 + j * h2) % table_size for j in range(table_size)]\n permutations.append(perm)\n\n table = [-1] * table_size\n next_idx = [0] * n\n filled = 0\n\n while filled < table_size:\n for i in range(n):\n while table[permutations[i][next_idx[i]]] != -1:\n next_idx[i] += 1\n table[permutations[i][next_idx[i]]] = i\n next_idx[i] += 1\n filled += 1\n if filled == table_size:\n break\n return table\n```\n\nLa ventaja de Maglev sobre consistent hashing basado en anillo: uniformidad casi perfecta.\n\n## Power of Two Choices (P2C)\n\nP2C es hermosamente simple: en vez de elegir un backend aleatorio, elegir dos backends aleatorios y mandá el request al que tenga menos conexiones activas.\n\nEl resultado teórico es notable: selección aleatoria da O(log n / log log n) de carga máxima, pero P2C da O(log log n). Esa elección extra reduce exponencialmente el peor caso.\n\n## Configuraciones Reales de Producción\n\n### HAProxy\n\n```haproxy\n# Backend con least connections - para API con latencia variable\nbackend api_servers\n balance leastconn\n option httpchk GET /health\n http-check expect status 200\n default-server inter 3s fall 3 rise 2 slowstart 30s\n server api-1 10.0.1.10:8080 check weight 100\n server api-2 10.0.1.11:8080 check weight 100\n server api-3 10.0.1.12:8080 check weight 50 # Instancia más chica\n\n# Backend con consistent hashing + cargas acotadas - para afinidad de cache\nbackend cache_servers\n balance uri\n hash-type consistent sdbm\n hash-balance-factor 150\n server cache-1 10.0.2.10:8080 check\n server cache-2 10.0.2.11:8080 check\n\n# Backend con P2C - para cargas de trabajo generales\nbackend web_servers\n balance random(2)\n server web-1 10.0.3.10:8080 check\n server web-2 10.0.3.11:8080 check\n```\n\n### Envoy\n\n```yaml\nclusters:\n - name: api_cluster\n lb_policy: LEAST_REQUEST\n least_request_lb_config:\n choice_count: 3 # P3C - elegir el mejor de 3\n - name: cache_cluster\n lb_policy: RING_HASH\n ring_hash_lb_config:\n minimum_ring_size: 1024\n hash_function: XX_HASH\n - name: websocket_cluster\n lb_policy: LEAST_REQUEST\n common_lb_config:\n healthy_panic_threshold:\n value: 50\n```\n\nEl ` healthy_panic_threshold ` para backends de WebSocket es crítico. Sin él, si dos de cuatro backends fallan health checks, Envoy solo manda tráfico a los dos sanos, que podrían sobrecargarse. Con el threshold en 50%, si más de la mitad falla, Envoy manda tráfico a todos (incluyendo los \"unhealthy\") bajo la teoría de que servicio parcial es mejor que falla en cascada.\n\n## Recomendaciones Prácticas\n\nDespués de correr estos algoritmos en producción con diferentes cargas de trabajo, los siguientes defaults emergen:\n\n- **APIs HTTP stateless**: ` leastconn ` (HAProxy) o ` LEAST_REQUEST ` con ` choice_count: 2 ` (Envoy).\n- **Capas de cache**: Consistent hashing con cargas acotadas.\n- **WebSocket/gRPC streams**: Least connections, siempre.\n- **Tráfico web general**: P2C.\n\nP2C es quizás el algoritmo más impactante en esta comparación. La realización de que una elección aleatoria extra puede reducir exponencialmente la carga del peor caso es un insight poderoso. Usar ` random(2) ` en HAProxy para cualquier backend sin una razón fuerte para usar otra cosa es un default pragmático.\n\n## Preguntas frecuentes\n\n### ¿Qué algoritmo de balanceo de carga debería usar por defecto?\n\nRound-robin para servicios HTTP stateless. Least connections para servicios con duración de request variable. Consistent hashing solo cuando se necesita afinidad de sesión o localidad de cache. P2C cuando se desea simplicidad con distribución de carga casi óptima.\n\n### ¿Qué es Maglev hashing y cuándo debería usarlo?\n\nMaglev es el algoritmo de consistent hashing de Google diseñado para su network load balancer. Provee mínima disrupción cuando los backends cambian y distribución extremadamente uniforme. Usalo cuando estés construyendo un L4 load balancer custom o cuando necesités mejor distribución que consistent hashing basado en anillo.\n\n### ¿Cómo funciona consistent hashing con cargas acotadas?\n\nEs consistent hashing con un tope: ningún backend puede recibir más de (1 + epsilon) veces la carga promedio. Cuando un backend alcanza su límite, el request se derrama al siguiente nodo del anillo.\n\n## Tips\n\n1. **Tip:** Utilizar ` leastconn ` para conexiones de larga duración (WebSocket, gRPC streams) y ` roundrobin ` para requests HTTP cortos. Mezclarlos es el error más común de load balancing.\n2. **Tip:** El ` RING_HASH ` de Envoy con ` minimum_ring_size: 1024 ` proporciona consistent hashing que sobrevive adiciones de backends sin redistribuir todas las conexiones.\n3. **Tip:** Power of Two Choices (P2C) supera a selección puramente aleatoria de forma significativa. El ` random(2) ` de HAProxy proporciona P2C con cero complejidad de configuración.\n4. **Tip:** Siempre configurar ` hash-balance-factor ` en HAProxy al usar consistent hashing. Sin él, una hot key manda 100% del tráfico a un backend. Un factor de 150 limita cualquier backend a 1.5x la carga promedio.\n\n- load-balancing\n- maglev\n- consistent-hashing\n- p2c\n- haproxy\n- envoy\n- infrastructure\n\n[Volver al Blog](<https://lucioduran.com/es/blog>)","headings":[{"level":1,"text":"Algoritmos de Balanceo de Carga: Maglev Hashing, Consistent Hashing con Cargas Acotadas y P2C","url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#title"},{"level":2,"text":"Fundamentos: por qué round-robin falla","url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#fundamentos-por-qu-round-robin-falla"},{"level":2,"text":"Consistent Hashing: El Problema de Localidad de Cache","url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#consistent-hashing-el-problema-de-localidad-de-cache"},{"level":3,"text":"Consistent Hashing con Cargas Acotadas","url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#consistent-hashing-con-cargas-acotadas"},{"level":2,"text":"Maglev Hashing: El Algoritmo de Producción de Google","url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#maglev-hashing-el-algoritmo-de-produccin-de-google"},{"level":2,"text":"Power of Two Choices (P2C)","url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#power-of-two-choices-p2c"},{"level":2,"text":"Configuraciones Reales de Producción","url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#configuraciones-reales-de-produccin"},{"level":3,"text":"HAProxy","url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#haproxy"},{"level":3,"text":"Envoy","url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#envoy"},{"level":2,"text":"Recomendaciones Prácticas","url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#recomendaciones-prcticas"},{"level":2,"text":"Preguntas frecuentes","url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#questions"},{"level":3,"text":"¿Qué algoritmo de balanceo de carga debería usar por defecto?","url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#question-1"},{"level":3,"text":"¿Qué es Maglev hashing y cuándo debería usarlo?","url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#question-2"},{"level":3,"text":"¿Cómo funciona consistent hashing con cargas acotadas?","url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#question-3"},{"level":2,"text":"Tips","url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#article-tips"}],"sections":[{"heading":"Algoritmos de Balanceo de Carga: Maglev Hashing, Consistent Hashing con Cargas Acotadas y P2C","level":1,"url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing","content":"Infrastructure"},{"heading":"Algoritmos de Balanceo de Carga: Maglev Hashing, Consistent Hashing con Cargas Acotadas y P2C","level":1,"url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#title","content":"2026-01-305 min lectura\n\nLucio Durán\nEngineering Manager & AI Solutions Architect\n\nTambién disponible en: [English](<https://lucioduran.com/blog/load-balancing-algorithms-maglev-consistent-hashing>)"},{"heading":"Fundamentos: por qué round-robin falla","level":2,"url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#fundamentos-por-qu-round-robin-falla","content":"Round-robin asume que todos los requests cuestan lo mismo y todos los backends tienen la misma capacidad. Ninguna de las dos cosas es cierta en la práctica.\n\n```python\n# simulation.py - Por qué round-robin falla con latencia variable\nimport random\nimport statistics\nfrom dataclasses import dataclass, field\n\n@dataclass\nclass Backend:\n name: str\n capacity: int\n active: int = 0\n total_served: int = 0\n latencies: list = field(default_factory=list)\n\ndef simulate_round_robin(backends, requests):\n idx = 0\n for _ in range(requests):\n backend = backends[idx % len(backends)]\n latency = random.expovariate(1/50) if random.random() < 0.1 else random.expovariate(1/2)\n backend.active += 1\n backend.total_served += 1\n backend.latencies.append(latency)\n if backend.active > backend.capacity:\n backend.latencies[-1] *= 3\n backend.active = max(0, backend.active - 1)\n idx += 1\n\ndef simulate_least_conn(backends, requests):\n for _ in range(requests):\n backend = min(backends, key=lambda b: b.active)\n latency = random.expovariate(1/50) if random.random() < 0.1 else random.expovariate(1/2)\n backend.active += 1\n backend.total_served += 1\n backend.latencies.append(latency)\n if backend.active > backend.capacity:\n backend.latencies[-1] *= 3\n backend.active = max(0, backend.active - 1)\n\nrr_backends = [Backend(f\"rr-{i}\", capacity=50) for i in range(5)]\nlc_backends = [Backend(f\"lc-{i}\", capacity=50) for i in range(5)]\n\nsimulate_round_robin(rr_backends, 10000)\nsimulate_least_conn(lc_backends, 10000)\n\n# Output típico:\n# Round Robin: p99 rango = 142.3ms - 148.7ms (todos los backends sufren igual)\n# Least Conn: p99 rango = 4.8ms - 7.2ms (requests lentos concentrados)\n```"},{"heading":"Consistent Hashing: El Problema de Localidad de Cache","level":2,"url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#consistent-hashing-el-problema-de-localidad-de-cache","content":"Consistent hashing mapea tanto keys como servidores a un anillo. Una key es servida por el siguiente servidor en sentido horario. Cuando se agrega o elimina un servidor, solo las keys que estaban asignadas a él se remapean.\n\nEl problema: hot keys. Si el 30% de tu tráfico pega en una sola cache key, consistent hashing manda el 30% del tráfico a un solo backend."},{"heading":"Consistent Hashing con Cargas Acotadas","level":3,"url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#consistent-hashing-con-cargas-acotadas","content":"El paper de Google de 2017 introdujo un fix: poner un tope a la carga máxima de cualquier backend. Cuando un backend alcanza su límite, el request se derrama al siguiente nodo del anillo.\n\n```go\nfunc (ch *BoundedConsistentHash) GetNode(key string, loads map[string]int, avgLoad float64, epsilon float64) string {\n ch.mu.RLock()\n defer ch.mu.RUnlock()\n\n maxLoad := int(avgLoad * (1 + epsilon))\n h := ch.hash(key)\n idx := sort.Search(len(ch.ring), func(i int) bool { return ch.ring[i] >= h })\n\n for i := 0; i < len(ch.ring); i++ {\n nodeIdx := (idx + i) % len(ch.ring)\n node := ch.nodes[ch.ring[nodeIdx]]\n if loads[node] < maxLoad {\n return node\n }\n }\n return ch.nodes[ch.ring[idx]]\n}\n```\n\nCon ` epsilon = 0.25 `, ningún backend recibe más del 125% de la carga promedio."},{"heading":"Maglev Hashing: El Algoritmo de Producción de Google","level":2,"url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#maglev-hashing-el-algoritmo-de-produccin-de-google","content":"Maglev genera una tabla de lookup donde cada entrada mapea a un backend. La construcción de la tabla asegura mínima disrupción cuando los backends cambian.\n\n```python\n# maglev.py\ndef maglev_table(backends: list[str], table_size: int = 65537) -> list[int]:\n n = len(backends)\n permutations = []\n for backend in backends:\n h1 = hash(backend + \"_offset\") % table_size\n h2 = (hash(backend + \"_skip\") % (table_size - 1)) + 1\n perm = [(h1 + j * h2) % table_size for j in range(table_size)]\n permutations.append(perm)\n\n table = [-1] * table_size\n next_idx = [0] * n\n filled = 0\n\n while filled < table_size:\n for i in range(n):\n while table[permutations[i][next_idx[i]]] != -1:\n next_idx[i] += 1\n table[permutations[i][next_idx[i]]] = i\n next_idx[i] += 1\n filled += 1\n if filled == table_size:\n break\n return table\n```\n\nLa ventaja de Maglev sobre consistent hashing basado en anillo: uniformidad casi perfecta."},{"heading":"Power of Two Choices (P2C)","level":2,"url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#power-of-two-choices-p2c","content":"P2C es hermosamente simple: en vez de elegir un backend aleatorio, elegir dos backends aleatorios y mandá el request al que tenga menos conexiones activas.\n\nEl resultado teórico es notable: selección aleatoria da O(log n / log log n) de carga máxima, pero P2C da O(log log n). Esa elección extra reduce exponencialmente el peor caso."},{"heading":"Configuraciones Reales de Producción","level":2,"url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#configuraciones-reales-de-produccin","content":""},{"heading":"HAProxy","level":3,"url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#haproxy","content":"```haproxy\n# Backend con least connections - para API con latencia variable\nbackend api_servers\n balance leastconn\n option httpchk GET /health\n http-check expect status 200\n default-server inter 3s fall 3 rise 2 slowstart 30s\n server api-1 10.0.1.10:8080 check weight 100\n server api-2 10.0.1.11:8080 check weight 100\n server api-3 10.0.1.12:8080 check weight 50 # Instancia más chica\n\n# Backend con consistent hashing + cargas acotadas - para afinidad de cache\nbackend cache_servers\n balance uri\n hash-type consistent sdbm\n hash-balance-factor 150\n server cache-1 10.0.2.10:8080 check\n server cache-2 10.0.2.11:8080 check\n\n# Backend con P2C - para cargas de trabajo generales\nbackend web_servers\n balance random(2)\n server web-1 10.0.3.10:8080 check\n server web-2 10.0.3.11:8080 check\n```"},{"heading":"Envoy","level":3,"url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#envoy","content":"```yaml\nclusters:\n - name: api_cluster\n lb_policy: LEAST_REQUEST\n least_request_lb_config:\n choice_count: 3 # P3C - elegir el mejor de 3\n - name: cache_cluster\n lb_policy: RING_HASH\n ring_hash_lb_config:\n minimum_ring_size: 1024\n hash_function: XX_HASH\n - name: websocket_cluster\n lb_policy: LEAST_REQUEST\n common_lb_config:\n healthy_panic_threshold:\n value: 50\n```\n\nEl ` healthy_panic_threshold ` para backends de WebSocket es crítico. Sin él, si dos de cuatro backends fallan health checks, Envoy solo manda tráfico a los dos sanos, que podrían sobrecargarse. Con el threshold en 50%, si más de la mitad falla, Envoy manda tráfico a todos (incluyendo los \"unhealthy\") bajo la teoría de que servicio parcial es mejor que falla en cascada."},{"heading":"Recomendaciones Prácticas","level":2,"url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#recomendaciones-prcticas","content":"Después de correr estos algoritmos en producción con diferentes cargas de trabajo, los siguientes defaults emergen:\n\n- **APIs HTTP stateless**: ` leastconn ` (HAProxy) o ` LEAST_REQUEST ` con ` choice_count: 2 ` (Envoy).\n- **Capas de cache**: Consistent hashing con cargas acotadas.\n- **WebSocket/gRPC streams**: Least connections, siempre.\n- **Tráfico web general**: P2C.\n\nP2C es quizás el algoritmo más impactante en esta comparación. La realización de que una elección aleatoria extra puede reducir exponencialmente la carga del peor caso es un insight poderoso. Usar ` random(2) ` en HAProxy para cualquier backend sin una razón fuerte para usar otra cosa es un default pragmático."},{"heading":"Preguntas frecuentes","level":2,"url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#questions","content":""},{"heading":"¿Qué algoritmo de balanceo de carga debería usar por defecto?","level":3,"url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#question-1","content":"Round-robin para servicios HTTP stateless. Least connections para servicios con duración de request variable. Consistent hashing solo cuando se necesita afinidad de sesión o localidad de cache. P2C cuando se desea simplicidad con distribución de carga casi óptima."},{"heading":"¿Qué es Maglev hashing y cuándo debería usarlo?","level":3,"url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#question-2","content":"Maglev es el algoritmo de consistent hashing de Google diseñado para su network load balancer. Provee mínima disrupción cuando los backends cambian y distribución extremadamente uniforme. Usalo cuando estés construyendo un L4 load balancer custom o cuando necesités mejor distribución que consistent hashing basado en anillo."},{"heading":"¿Cómo funciona consistent hashing con cargas acotadas?","level":3,"url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#question-3","content":"Es consistent hashing con un tope: ningún backend puede recibir más de (1 + epsilon) veces la carga promedio. Cuando un backend alcanza su límite, el request se derrama al siguiente nodo del anillo."},{"heading":"Tips","level":2,"url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#article-tips","content":"1. **Tip:** Utilizar ` leastconn ` para conexiones de larga duración (WebSocket, gRPC streams) y ` roundrobin ` para requests HTTP cortos. Mezclarlos es el error más común de load balancing.\n2. **Tip:** El ` RING_HASH ` de Envoy con ` minimum_ring_size: 1024 ` proporciona consistent hashing que sobrevive adiciones de backends sin redistribuir todas las conexiones.\n3. **Tip:** Power of Two Choices (P2C) supera a selección puramente aleatoria de forma significativa. El ` random(2) ` de HAProxy proporciona P2C con cero complejidad de configuración.\n4. **Tip:** Siempre configurar ` hash-balance-factor ` en HAProxy al usar consistent hashing. Sin él, una hot key manda 100% del tráfico a un backend. Un factor de 150 limita cualquier backend a 1.5x la carga promedio.\n\n- load-balancing\n- maglev\n- consistent-hashing\n- p2c\n- haproxy\n- envoy\n- infrastructure\n\n[Volver al Blog](<https://lucioduran.com/es/blog>)"}],"links":[{"text":"English","url":"https://lucioduran.com/blog/load-balancing-algorithms-maglev-consistent-hashing"},{"text":"Volver al Blog","url":"https://lucioduran.com/es/blog"}],"structuredData":[{"@context":"https://schema.org","@graph":[{"@type":"BlogPosting","@id":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing#article","mainEntityOfPage":{"@type":"WebPage","@id":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing"},"headline":"Algoritmos de Balanceo de Carga: Maglev Hashing, Consistent Hashing con Cargas Acotadas y P2C","description":"Análisis de algoritmos modernos de balanceo de carga, Maglev hashing de Google, consistent hashing con cargas acotadas, power of two choices y configuraciones de producción de HAProxy/Envoy.","datePublished":"2026-01-30","author":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"publisher":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"image":"https://lucioduran.com/favicons/og-default.png","url":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing","inLanguage":"es","isPartOf":{"@id":"https://lucioduran.com/blog#blog"},"articleSection":"Infrastructure","keywords":"load-balancing, maglev, consistent-hashing, p2c, haproxy, envoy, infrastructure","wordCount":912,"timeRequired":"PT5M","workTranslation":[{"@type":"BlogPosting","inLanguage":"en","url":"https://lucioduran.com/blog/load-balancing-algorithms-maglev-consistent-hashing"}]},{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Inicio","item":"https://lucioduran.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://lucioduran.com/es/blog"},{"@type":"ListItem","position":3,"name":"Algoritmos de Balanceo de Carga: Maglev Hashing, Consistent Hashing con Cargas Acotadas y P2C","item":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing"}]},{"@type":"FAQPage","mainEntity":[{"@type":"Question","name":"¿Qué algoritmo de balanceo de carga debería usar por defecto?","acceptedAnswer":{"@type":"Answer","text":"Round-robin para servicios HTTP stateless. Least connections para servicios con duración de request variable. Consistent hashing solo cuando se necesita afinidad de sesión o localidad de cache. P2C cuando se desea simplicidad con distribución de carga casi óptima."}},{"@type":"Question","name":"¿Qué es Maglev hashing y cuándo debería usarlo?","acceptedAnswer":{"@type":"Answer","text":"Maglev es el algoritmo de consistent hashing de Google diseñado para su network load balancer. Provee mínima disrupción cuando los backends cambian y distribución extremadamente uniforme. Usalo cuando estés construyendo un L4 load balancer custom o cuando necesités mejor distribución que consistent hashing basado en anillo."}},{"@type":"Question","name":"¿Cómo funciona consistent hashing con cargas acotadas?","acceptedAnswer":{"@type":"Answer","text":"Es consistent hashing con un tope: ningún backend puede recibir más de (1 + epsilon) veces la carga promedio. Cuando un backend alcanza su límite, el request se derrama al siguiente nodo del anillo."}}]}]}],"contentHash":"329bcf9a5ea1dbec50ac47bfddaf5b3e709abbaeb6ef309f6224df523e07cf36","provenance":{"method":"Deterministic serialization of the server-rendered main element","source":"https://lucioduran.com/es/blog/load-balancing-algorithms-maglev-consistent-hashing","hashAlgorithm":"sha256","hashScope":"JSON document fields before contentHash and provenance","sourceHTMLBytes":54172,"contentBytes":8883}}