Balanceadores de Carga

Resumen

Un balanceador de carga —load balancer— es un componente que recibe las solicitudes de los clientes y las distribuye entre varios servidores backend según una política configurable. Actúa como un director de tráfico: el cliente solo conoce la dirección del balanceador, y es el balanceador quien decide qué instancia atiende cada request.

Importa porque es la pieza que habilita la escalabilidad horizontal en la práctica. Sin un balanceador, agregar más instancias no sirve de nada: los clientes no saben a cuál conectarse. Con un balanceador, el cliente ve una sola dirección y el balanceador reparte la carga transparentemente.

Además de distribuir tráfico, los balanceadores modernos hacen health checks —detectan instancias caídas y dejan de enviarles tráfico—, terminación SSL, compresión, y en algunos casos caching y rate limiting.

Alcance y supuestos

Este paquete cubre el concepto a nivel arquitectónico: qué es, qué problema resuelve, cómo se relaciona con otros patrones del ecosistema, y en qué contexto tiene sentido aplicarlo. No cubre detalles de implementación específicos de cada tecnología ni configuraciones de proveedores cloud concretos. Asume que el lector entiende los fundamentos de sistemas distribuidos y arquitectura de software.

Modelo mental

La recepción de un edificio de oficinas. Cuando llegás, no sabés en qué piso ni en qué escritorio está la persona que necesitás. La recepcionista te deriva según a quién buscás y qué tan ocupado está cada equipo. Si un equipo está en una reunión, te deriva a otro. Si un piso está cerrado por mantenimiento, no te manda ahí. El balanceador de carga es esa recepcionista.

Uso práctico

Los balanceadores operan en dos capas principales:

Capa 4 (transporte — TCP/UDP): distribuyen tráfico basándose en IP y puerto, sin inspeccionar el contenido. Son más rápidos pero menos inteligentes. Ejemplo: HAProxy en modo TCP, AWS NLB.

Capa 7 (aplicación — HTTP/HTTPS): inspeccionan headers, cookies, path de la URL. Pueden enviar requests a distintas instancias según el contenido. Ejemplo: NGINX, Traefik, AWS ALB.

Algoritmos comunes de distribución:

| Algoritmo | Comportamiento | |---|---| | Round-robin | Cada request va a la siguiente instancia en orden circular | | Least connections | El request va a la instancia con menos conexiones activas | | IP hash | Requests del mismo cliente van siempre a la misma instancia | | Weighted | Instancias más potentes reciben más tráfico |

Un balanceador bien configurado también implementa sticky sessions cuando la aplicación lo requiere —aunque lo ideal es que la app sea stateless y no necesite stickiness—.

Ejemplo trabajado: configurar un balanceador para una API

Una API tiene 3 instancias backend. El balanceador NGINX con round-robin distribuye tráfico uniformemente. Una instancia empieza a fallar —health check detecta 3 fallos consecutivos— y el balanceador la marca como down, dejando de enviarle tráfico. Las 2 instancias restantes absorben la carga. Cuando la instancia se recupera, el balanceador la reincorpora automáticamente. Los usuarios nunca notaron la falla.

Evidencia

• Wikipedia, Load balancing cubre los algoritmos de distribución, las capas de operación y la evolución de los balanceadores desde hardware dedicado hasta software y cloud.