Skip to content
NeuralSkills
Despliegue

Configuracion de Balanceador de Carga

Configura estrategias de balanceo de carga que distribuyen el trafico eficientemente — desde round-robin hasta sticky sessions y ruteo basado en salud.

Intermedio Gratis Publicado: 15 de abril de 2026
Herramientas Compatibles claude-codechatgptgeminicopilotcursorwindsurfuniversal

El Problema

Tu servidor unico es un punto unico de fallo. Cuando el trafico sube, se derrumba. Cuando despliegas, se cae. Los balanceadores de carga resuelven esto, pero elegir el algoritmo incorrecto — o configurar mal los health checks — crea problemas peores que no tener balanceador: distribucion desigual de trafico, solicitudes enviadas a servidores muertos y datos de sesion perdidos entre solicitudes.

El Prompt

Eres un arquitecto de balanceo de carga. Diseña una estrategia de balanceo de carga para mi aplicacion.

CONTEXTO DE LA APLICACION:
- Arquitectura: [ej., 3 servidores Node.js, pods de Kubernetes, funciones serverless]
- Volumen de trafico: [ej., 1000 req/min, 50k usuarios concurrentes, rafagas/constante]
- Manejo de sesiones: [ej., JWT stateless, sesiones del lado del servidor, conexiones WebSocket]
- Endpoint de health check: [ej., /health, /api/status, ninguno aun]
- Plataforma: [ej., AWS ALB/NLB, Nginx, HAProxy, Cloudflare, Traefik]

Diseña la estrategia de balanceo de carga:
1. **Seleccion de algoritmo**: Compara round-robin, least-connections, weighted, IP-hash para mi caso. Recomienda con justificacion.
2. **Configuracion de health check**: Define endpoint, intervalo, umbrales y que constituye "saludable."
3. **Persistencia de sesion**: Como manejar afinidad de sesion sin romper el escalado horizontal.
4. **Terminacion SSL**: Donde terminar SSL (balanceador vs backend) con implicaciones de rendimiento.
5. **Comportamiento de failover**: Que sucede cuando un backend cae — drain, retry, circuit break.
6. **Configuracion**: Proporciona la configuracion exacta para mi plataforma.

Ejemplo de Salida

Estrategia: Least-connections (recomendado para tu API con duracion variable de solicitudes)
Health Check: GET /health cada 10s, saludable despues de 2 exitos, no saludable despues de 3 fallos
  /health retorna: { status: "ok", db: "connected", uptime: 3600 }
Sesion: JWT stateless — no se necesitan sticky sessions, simplifica el escalado
SSL: Terminar en ALB (descarga overhead TLS de los servidores de app, centraliza gestion de certificados)
Failover: Connection draining 30s antes de remover target no saludable, retry en 502/503 (max 2 reintentos)

Cuando Usarlo

Usa este skill al agregar un segundo servidor, prepararte para crecimiento de trafico o configurar alta disponibilidad. Esencial al desplegar detras de balanceadores de carga en la nube por primera vez, o al depurar distribucion desigual de trafico entre servidores backend.

Consejos Pro

  • Los health checks deben probar dependencias reales — un /health que devuelve 200 sin verificar la conexion a la base de datos enviara felizmente trafico a un servidor que no puede atender solicitudes reales.
  • El connection draining previene solicitudes interrumpidas — al remover un servidor del pool, drena conexiones activas (30-60 segundos) en vez de cortarlas inmediatamente.
  • Las conexiones WebSocket necesitan reglas diferentes — el balanceo HTTP estandar rompe conexiones persistentes. Usa balanceo basado en conexion o un listener separado para trafico WebSocket.
  • Monitorea metricas por backend — si un servidor tiene consistentemente mayor latencia o tasas de error, el balanceador funciona pero algo esta mal con esa instancia especifica.