Load balancers: qué resuelven y qué no en una aplicación

Load balancers: qué resuelven y qué no en una aplicación 

Cuando una aplicación empieza a fallar, ponerse lenta o recibir más tráfico del esperado, una de las primeras respuestas suele ser: “pongámosle un load balancer”.

La idea tiene sentido hasta cierto punto. Un load balancer ayuda a distribuir solicitudes entre varios servidores, evita enviar tráfico a targets que fallan health checks y permite operar aplicaciones con más disponibilidad. En AWS, Elastic Load Balancing está diseñado para alta disponibilidad, escalado automático y distribución de tráfico entre distintos tipos de targets y zonas de disponibilidad.

Pero hay una diferencia importante entre distribuir tráfico y resolver el problema real de una aplicación.

Un load balancer puede decidir a dónde mandar una petición. Lo que no puede hacer es optimizar una query lenta, arreglar un bug, reducir el consumo excesivo de memoria o hacer que una base de datos saturada responda mejor.

Muestra que, en escenarios de mucho tráfico, el diseño puede requerir distribuir la carga entre varios load balancers, no solo agregar uno al frente de la aplicación 

Qué sí hace un load balancer

La función principal de un load balancer es actuar como punto de entrada para el tráfico. En lugar de que los clientes llamen directamente a una instancia o contenedor, llaman a un endpoint común. El load balancer recibe esa solicitud y la envía a uno de los targets disponibles.

Esto aporta tres beneficios importantes.

Primero, permite distribuir carga. Si hay varias instancias sanas detrás, el tráfico puede repartirse entre ellas. Esto reduce la dependencia de un solo servidor y permite escalar horizontalmente.

Segundo, mejora la disponibilidad. Si un target deja de responder correctamente, el load balancer puede sacarlo de rotación y continuar enviando tráfico a los targets que siguen sanos. Para eso se apoya en health checks, que son señales usadas para decidir si un backend debe seguir recibiendo solicitudes.

Tercero, desacopla a los clientes de la infraestructura real. Los usuarios no necesitan saber cuántas instancias hay detrás, si una fue reemplazada o si el sistema está corriendo en varias zonas. El load balancer mantiene un punto de entrada estable mientras la infraestructura puede cambiar por detrás.

Hasta ahí, el load balancer aporta muchísimo valor. El problema empieza cuando se le atribuyen capacidades que en realidad pertenecen al diseño de la aplicación y sus dependencias. 

Qué no hace un load balancer

El problema aparece cuando se espera que el load balancer resuelva cosas para las que no fue diseñado.

Un load balancer no arregla una aplicación lenta. Si cada request tarda demasiado porque el código hace trabajo innecesario, porque hay llamadas secuenciales mal diseñadas o porque la base de datos responde lento, el load balancer no reduce mágicamente ese tiempo.

Tampoco corrige una mala arquitectura. Si todos los targets dependen de la misma base de datos saturada, agregar más instancias detrás del load balancer puede incluso aumentar la presión sobre ese cuello de botella. El tráfico queda mejor repartido, sí, pero el problema central sigue intacto.

También es importante entender que un load balancer no garantiza estabilidad por sí solo. Si todos los targets tienen el mismo bug, si todos fueron desplegados con una configuración incorrecta o si todos dependen de un servicio externo que está fallando, no hay un backend sano al cual enviar tráfico.

En otras palabras: el load balancer puede enrutar alrededor de fallos aislados, pero no puede salvar un sistema cuando la falla es compartida por todos los componentes.

Healthy no siempre significa estable

Uno de los puntos más delicados es la interpretación de los health checks.

Que una instancia pase un health check no significa necesariamente que la aplicación esté bien para los usuarios. AWS diferencia entre health checks superficiales y profundos. Los superficiales validan cosas locales, como que procesos críticos estén corriendo o que la instancia responda. Los profundos también prueban interacciones con dependencias externas, como una base de datos o un servicio downstream.

Ambos enfoques tienen ventajas y riesgos.

Un health check superficial puede decir “todo bien” aunque la aplicación no pueda conectarse a una dependencia importante. Desde el punto de vista del load balancer, el target está vivo. Desde el punto de vista del usuario, la aplicación puede estar fallando.

Un health check profundo puede detectar mejor problemas reales de extremo a extremo, pero también puede generar efectos no deseados. Si una dependencia externa falla de forma temporal, muchas instancias podrían parecer no saludables aunque localmente estén bien. AWS advierte que agregar checks profundos al Auto Scaling Group puede provocar reemplazos innecesarios de instancias sanas durante fallas transitorias de dependencias.

La conclusión es simple: los health checks son necesarios, pero no son una definición perfecta de salud. Son una señal operativa, no una prueba absoluta de que todo el sistema funciona bien.

Las fallas grises: cuando algo parece sano, pero no lo está

En producción no todo falla de forma clara. A veces un target no está completamente caído, pero se comporta peor que los demás. Puede devolver más errores, tener más latencia, fallar solo en ciertas rutas o degradarse bajo carga.

AWS llama a este tipo de situación una gray failure: el target pasa los health checks activos del load balancer, pero aun así devuelve errores. Esto puede pasar por bugs en la aplicación, fallas de dependencias, pérdida intermitente de red, caché fría, sobrecarga de CPU u otras causas.

Para estos casos, AWS ofrece Application Load Balancer Automatic Target Weights. Esta capacidad detecta targets con una proporción anómala de errores y reduce el tráfico hacia ellos, enviando más solicitudes a targets que están respondiendo mejor.

Eso es muy útil, pero no cambia el mensaje principal: el load balancer está mitigando el impacto, no arreglando la causa.

Si un target tiene un bug, el bug sigue ahí.
Si una instancia está sobrecargada, la sobrecarga sigue ahí.
Si una dependencia está fallando, la dependencia sigue siendo el problema.

El load balancer ayuda a que menos usuarios sufran el error, pero el equipo todavía tiene que investigar y corregir el origen.

Balancear carga no es lo mismo que optimizar rendimiento

Este es el error más común: pensar que balancear tráfico equivale automáticamente a mejorar performance.

Sí mejora cuando el problema es falta de capacidad en los servidores de aplicación y esos servidores pueden escalar horizontalmente. Por ejemplo, si una instancia puede atender cierta cantidad de tráfico y agregamos más instancias sanas detrás del load balancer, el sistema puede procesar más solicitudes.

Pero si el cuello de botella está en otro lugar, el resultado puede ser distinto.

Si la base de datos está saturada, más instancias pueden generar más conexiones y más consultas contra la misma base. Si un endpoint hace demasiado trabajo por request, más targets solo reparten ese trabajo costoso. Si una dependencia externa está lenta, todos los servidores van a esperar por la misma dependencia.

El load balancer reparte solicitudes. No reduce automáticamente el costo de procesarlas.

Por eso, antes de pensar que un load balancer resolverá un problema de rendimiento, conviene preguntar: ¿el cuello de botella está en la distribución del tráfico o en la forma en que la aplicación procesa cada solicitud?

El load balancer como parte de la arquitectura, no como solución completa

Un load balancer aporta más valor cuando forma parte de una arquitectura bien diseñada. Funciona mejor cuando la aplicación puede escalar horizontalmente, cuando los health checks reflejan señales útiles, cuando las dependencias tienen límites claros y cuando existe observabilidad suficiente para entender dónde está fallando el sistema.

También es importante recordar que el propio balanceo de carga puede requerir diseño. En el blog de AWS sobre estrategias de escalado para Elastic Load Balancing, se explica que en ciertos escenarios de alto tráfico puede ser necesario aplicar sharding de ELB, distribuyendo la carga entre varios load balancers mediante DNS y Route 53.

Eso refuerza la idea central: un load balancer no es una caja mágica que se pone al frente y resuelve todo. Es una capa de control de tráfico dentro de un sistema más grande.

Cierre

Los load balancers son fundamentales en arquitecturas modernas. Ayudan a distribuir tráfico, mejorar disponibilidad, sacar de rotación targets no saludables y reducir el impacto de ciertos fallos.

Pero no deben confundirse con una solución automática para problemas de rendimiento o estabilidad.

Un load balancer no optimiza código lento.
No arregla queries pesadas.
No corrige bugs.
No elimina dependencias frágiles.
No convierte una arquitectura débil en una arquitectura resiliente.

Su verdadero rol es otro: hacer que una aplicación bien diseñada pueda recibir tráfico de forma más ordenada, disponible y controlada.

“Un load balancer no salva una mala aplicación; ayuda a que una buena arquitectura maneje mejor el tráfico”

Verifica antes de añadir un load balancer

Un load balancer amplifica lo que ya tienes. Si tu aplicación es estable, stateless y escala horizontalmente sin fricción, Elastic Load Balancing la hará más resiliente y distribuida. Pero si arrastra queries no optimizadas, fugas de memoria o sesiones atadas a una sola instancia, el load balancer solo distribuirá esos problemas entre más nodos —y los hará más difíciles de diagnosticar.

Antes de implementarlo, recorre esta checklist. Cada punto resuelve una dependencia real que el load balancer no cubre por sí mismo.

1. 1Haz tu aplicación statelessMueve sesiones y estado a un almacenamiento compartido (Redis, DynamoDB, S3). Si una instancia guarda estado local, las peticiones redistribuidas fallarán de forma inconsistente.
2. 2Optimiza queries frecuentesRevisa planes de ejecución, crea índices compuestos y elimina queries N+1. Una query lenta sigue siendo lenta sin importar qué instancia la reciba.
3. 3Verifica concurrencia en base de datosAsegúrate de que tu base de datos soporte conexiones simultáneas desde múltiples instancias. Considera connection pooling (PgBouncer, ProxySQL) o estrategias como sharding si la carga lo requiere.
4. 4Confirma que tus health checks son significativosUn endpoint que solo devuelve 200 sin validar dependencias reales genera falsos positivos. Configura health checks que verifiquen conectividad a base de datos, caches y servicios críticos.
5. 5Mide línea base antes de implementarDocumenta latencia P50/P95/P99, tasa de errores y tiempo de respuesta de endpoints clave. Estos números son tu referencia para evaluar si el load balancer mejora o enmascara problemas existentes.