Un load balancer es el componente que reparte el tráfico entrante entre múltiples servidores backend con dos objetivos: alta disponibilidad (si un servidor cae, los demás siguen sirviendo) y capacidad (un solo servidor pronto se queda corto). Es la pieza más básica de cualquier arquitectura escalable y, por debajo, está en prácticamente todos los servicios modernos, aunque muchas veces invisible.
Se distinguen dos niveles. Los L4 (TCP/UDP) balancean al nivel de la conexión, sin inspeccionar el contenido del protocolo: típicamente más rápidos, más simples, ideales para tráfico no HTTP (bases de datos, mensajería, cualquier protocolo binario). Los L7 (HTTP/HTTPS) entienden el protocolo: pueden enrutar por path o host, terminar TLS, reescribir headers, hacer routing por reglas finas (canary, A/B), aplicar autenticación o rate limiting.
Los algoritmos clásicos son round-robin (turno rotatorio), least-connections (al servidor con menos conexiones activas), consistent hashing (mismo cliente al mismo backend, importante para cachés) y weighted (servidores con distinta capacidad). Encima se montan health checks (sondas que verifican que los backends están vivos y excluyen automáticamente los que fallan) y sticky sessions cuando hace falta afinidad.
En 10Code los proveedores cloud ofrecen balanceadores gestionados que cubren la mayoría de casos: AWS ALB/NLB, Google Cloud Load Balancing, Azure Load Balancer/Application Gateway. Para deploys self-hosted usamos Nginx o HAProxy como L7, y Keepalived/MetalLB en bare metal cuando hace falta. En Kubernetes, los Services type LoadBalancer + Ingress (Nginx, Traefik) cubren la misma función dentro del cluster.
En 10Code llevamos más de una década aplicando estas tecnologías a productos reales. Si quieres comentarnos tu caso, escríbenos y te respondemos personalmente.
Hablar con un ingeniero