El problema que resuelve un Load Balancer
Imaginá que tenés un sitio de e-commerce y llega el Cyber Monday. El tráfico se multiplica por 10 en minutos. Un solo servidor no puede manejar toda la carga — se satura, las respuestas se hacen lentas, y eventualmente cae.
Un Load Balancer (balanceador de carga) distribuye ese tráfico entre múltiples servidores, de modo que ninguno se satura solo. Es la base de cualquier arquitectura de alta disponibilidad.
¿Qué es exactamente?
Un Load Balancer actúa como punto de entrada único para el tráfico externo y lo distribuye entre un grupo de servidores backend.
Internet → Load Balancer → Servidor 1
→ Servidor 2
→ Servidor 3
Los usuarios nunca saben cuántos servidores hay detrás — solo ven una IP o dominio.
Tipos de Load Balancer
Por capa de red
Capa 4 (TCP/UDP): balancea basándose en IP y puerto sin ver el contenido. Más rápido y simple.
Capa 7 (HTTP/HTTPS): puede leer el contenido de la request y tomar decisiones más inteligentes: redirigir /api a un grupo de servidores, /static a otro, según headers, cookies, etc.
Algoritmos de balanceo
Round Robin
Distribuye las requests en orden rotativo: server1, server2, server3, server1…
Least Connections
Manda cada nueva request al servidor con menos conexiones activas.
IP Hash
Basado en la IP del cliente, siempre manda las requests del mismo cliente al mismo servidor. Útil para apps con sesiones de servidor.
Weighted Round Robin
Como Round Robin, pero con pesos. Un servidor más potente puede recibir el doble de tráfico.
Health Checks: detectar servidores caídos
El LB envía periódicamente peticiones de health check (por ejemplo GET /health). Si el servidor no responde en X intentos, se marca como down y el tráfico se redirige a los restantes. Cuando se recupera, vuelve al pool automáticamente.
¿Cuándo necesitás un Load Balancer?
Alta disponibilidad (HA)
Si tu servicio no puede caerse (e-commerce, SaaS, API crítica), necesitás al menos 2 servidores detrás de un LB. Si uno cae, el otro sigue sirviendo tráfico sin interrupción.
Escalar horizontalmente
En lugar de contratar un servidor más grande (escala vertical), agregás más servidores iguales (escala horizontal). El LB los administra.
Deployments sin downtime
Podés hacer deployments sacando servidores del pool de a uno, actualizando, y volviéndolos a agregar — sin que el usuario lo note.
SSL Offloading
El LB puede terminar las conexiones HTTPS y hablar en HTTP plano con los backends. Reduce la carga de CPU en los servidores de aplicación.
Separación de cargas
/api → servidores Node.js
/ → servidores Nginx con archivos estáticos
/admin → un único servidor interno
¿Cuándo NO necesitás un Load Balancer?
Un Load Balancer no es necesario si:
- Tu app corre en un solo servidor y el tráfico es manejable
- Estás en etapa de desarrollo o prototipo
- El presupuesto no justifica la complejidad adicional
Un VPS bien dimensionado puede manejar miles de usuarios simultáneos.
Arquitectura típica con Load Balancer
┌─────────────────┐
│ Load Balancer │
│ (IP pública) │
└────────┬────────┘
│
┌───────────────┼───────────────┐
│ │ │
┌──────▼───┐ ┌──────▼───┐ ┌──────▼───┐
│ App #1 │ │ App #2 │ │ App #3 │
└──────────┘ └──────────┘ └──────────┘
│ │ │
└───────────────┼───────────────┘
│
┌────────▼────────┐
│ Base de datos │
└─────────────────┘
Load Balancer vs CDN vs DNS Round Robin
| Load Balancer | CDN | DNS Round Robin | |
|---|---|---|---|
| Qué balancea | Requests HTTP/TCP | Assets estáticos | Resolución de nombres |
| Health checks | Sí | Sí | No |
| Ideal para | Backends, APIs | Imágenes, JS, CSS | Distribución geográfica básica |
Si tu aplicación está creciendo y necesitás alta disponibilidad, revisá nuestros Load Balancers en Argentina.