Balanceadores de carga: la pieza invisible que evita que una web se caiga
Cuando una web funciona bien, nadie piensa en la infraestructura que hay detrás. La página carga, el pago se procesa, el vídeo se reproduce y todo parece sencillo. Pero en cuanto llegan muchos usuarios a la vez, un servidor falla o una aplicación empieza a responder lento, aparece una pregunta clave: ¿quién decide a qué máquina va cada petición? Ahí entra el balanceador de carga, una pieza discreta pero fundamental en cualquier arquitectura moderna. Bien diseñado puede marcar la diferencia entre una web que aguanta un pico de tráfico y otra que se cae justo cuando más visitas recibe.
Un único servidor es un punto único de fallo
Durante mucho tiempo, muchas webs vivían en un esquema simple: un servidor, una aplicación, una base de datos y poco más. Para proyectos pequeños puede ser suficiente. El problema aparece cuando esa única máquina concentra toda la responsabilidad. Si se satura la CPU, se queda sin memoria, falla el disco, se rompe una actualización o simplemente recibe más tráfico del previsto, toda la web queda afectada.
El balanceador de carga cambia ese modelo. En lugar de enviar todas las peticiones a un único servidor, se coloca delante de varios servidores capaces de responder al mismo servicio. Desde fuera, el usuario sigue entrando por una dirección normal. Por dentro, el balanceador decide qué servidor atiende cada conexión.
La idea no es solo repartir trabajo. También es reducir riesgo. Si una máquina deja de responder, el tráfico puede enviarse a otra. Esa es la base de la alta disponibilidad: no depender de una única pieza crítica.
Cómo reparte el tráfico sin que el usuario lo note
Un balanceador de carga puede usar varias estrategias para distribuir peticiones. La más fácil de entender es round robin: una petición va al servidor A, la siguiente al B, la siguiente al C, y vuelta a empezar. Es simple, pero no siempre óptima. No todos los servidores tienen la misma carga, ni todas las peticiones cuestan lo mismo.
Por eso existen algoritmos más inteligentes. Least connections envía tráfico al servidor con menos conexiones activas. Weighted round robin permite dar más peso a máquinas más potentes. También hay modelos basados en latencia, región geográfica, cabeceras HTTP o afinidad de sesión. La elección depende del tipo de aplicación.
En una web informativa, repartir peticiones de forma bastante uniforme puede bastar. En una aplicación con usuarios autenticados, carritos de compra o sesiones largas, hay que tener más cuidado. Si una sesión depende de memoria local en un servidor concreto, cambiar de backend a mitad de proceso puede romper la experiencia.
Por eso las arquitecturas modernas intentan que la aplicación sea lo más stateless posible: que cualquier servidor pueda atender cualquier petición usando almacenamiento compartido, bases de datos, cachés distribuidas o tokens.
Capa 4 y capa 7: no todos los balanceadores miran lo mismo
Una distinción importante es si el balanceador trabaja en capa 4 o en capa 7 del modelo OSI. No hace falta obsesionarse con la teoría, pero sí entender la diferencia práctica.
Un balanceador de capa 4 toma decisiones usando información de red y transporte: direcciones IP, puertos y protocolo, normalmente TCP o UDP. Es rápido, eficiente y adecuado para repartir conexiones sin inspeccionar demasiado el contenido. AWS, por ejemplo, describe su Network Load Balancer como una opción orientada a tráfico de alto rendimiento a nivel de conexión.
Un balanceador de capa 7 opera a nivel de aplicación. En HTTP o HTTPS puede mirar rutas, dominios, cabeceras, cookies o métodos. Eso permite reglas más expresivas: enviar /api a unos servidores, /imagenes a otros, separar tráfico móvil, aplicar redirecciones o enrutar según el host solicitado.
La capa 7 da más control, pero también añade complejidad. Puede terminar TLS, modificar cabeceras, integrarse con un WAF o actuar como proxy inverso. MDN explica bien el papel de los proxies inversos como intermediarios que protegen y organizan el acceso a los servidores.
Health checks: detectar fallos antes de enviar tráfico
El balanceo de carga no sirve de mucho si el sistema sigue enviando usuarios a un servidor roto. Por eso los health checks son una de sus funciones críticas. Un health check es una comprobación periódica para saber si un servidor está vivo, responde a tiempo y puede atender tráfico real.
La comprobación puede ser muy simple, como abrir una conexión TCP. Pero en aplicaciones serias suele convenir algo más específico: llamar a una ruta /health, comprobar que la aplicación responde, verificar que puede acceder a dependencias básicas o medir tiempos de respuesta. NGINX, por ejemplo, documenta distintos mecanismos de balanceo y comprobación de servidores.
Aquí hay un matiz importante: un servidor puede estar encendido y, aun así, no estar sano. Puede responder al ping, pero tener la aplicación bloqueada. Puede devolver HTTP 200, pero no poder conectar con la base de datos. Puede funcionar, pero tardar tanto que en la práctica degrade toda la experiencia.
Un buen health check debe ser suficientemente realista para detectar fallos relevantes, pero no tan pesado que genere más carga o dependa de demasiadas piezas. Es una decisión de diseño, no un trámite.
Balanceador, CDN y proxy inverso no son lo mismo
En una arquitectura web moderna es fácil mezclar conceptos: DNS, CDN, proxy inverso, balanceador, firewall, API gateway. A veces se solapan, pero no son lo mismo.
Una CDN acerca contenido al usuario y descarga al servidor de origen. En Tecnoic ya expliqué qué es una CDN y por qué Internet sería mucho más lento sin ella. Su objetivo principal es mejorar entrega, latencia y resistencia, sobre todo con contenido estático o cacheable.
Un balanceador de carga reparte tráfico entre varios destinos disponibles. Puede estar en el cloud, en un appliance físico, en software como HAProxy o NGINX, o integrado en una plataforma gestionada. Cloudflare también ofrece Load Balancing para distribuir tráfico entre endpoints, reducir latencia y mejorar disponibilidad.
Un proxy inverso, por su parte, se coloca delante de uno o varios servidores y actúa como fachada pública. Puede terminar TLS, aplicar reglas de seguridad, hacer caché, comprimir respuestas o enrutar peticiones. Muchos proxies inversos también balancean carga, y muchos balanceadores hacen funciones de proxy. Ahí nace la confusión.
Lo relevante es diseñar la cadena completa: quién resuelve el dominio, quién termina TLS, quién filtra tráfico, quién cachea, quién reparte carga y qué ocurre si falla cada pieza.
Errores habituales al diseñar alta disponibilidad
El primer error es pensar que poner un balanceador delante de dos servidores ya convierte una aplicación en altamente disponible. No necesariamente. Si ambos servidores dependen de una única base de datos sin réplica, de un único almacenamiento compartido mal diseñado o de una configuración manual difícil de reproducir, el punto único de fallo solo se ha movido.
El segundo error es ignorar el estado de sesión. Si cada servidor guarda información crítica en memoria local, el balanceador puede necesitar sticky sessions, es decir, mantener al usuario pegado al mismo backend. Eso puede funcionar, pero reduce flexibilidad y complica el escalado. Mejor diseñar aplicaciones preparadas para moverse entre nodos.
El tercer error es no probar fallos. La alta disponibilidad no se valida en una presentación de arquitectura, sino apagando nodos, simulando latencia, revisando métricas y comprobando que el tráfico realmente se desvía sin degradación grave.
También conviene vigilar el propio balanceador. Si solo hay uno y no está redundado, puede convertirse en el nuevo punto único de fallo. La pieza que evita caídas no debe ser, irónicamente, la más frágil del sistema.
Conclusión
Un balanceador de carga no es un accesorio reservado a gigantes tecnológicos. Es una pieza básica para construir servicios web más estables, escalables y mantenibles. Reparte tráfico, detecta servidores con problemas, facilita despliegues y ayuda a absorber picos sin que el usuario tenga que saber qué ocurre por detrás.
La clave está en no verlo como una caja mágica. Funciona bien cuando la aplicación, la red, la base de datos, la observabilidad y los procedimientos de despliegue están pensados en conjunto. ¿Has tenido alguna caída que se habría evitado con una arquitectura mejor balanceada? Ahí hay un buen debate técnico.