Published June 21, 2026 • 7 min read • Telecom Insights
The Load Balancer — also called an Application Delivery Controller (ADC) in its more feature-rich form — is the traffic director of modern distributed systems, distributing client requests across backend server pools to maximise throughput, minimise latency, and ensure high availability. Originally simple round-robin devices, load balancers now operate at both L4 (transport) and L7 (application) layers, performing SSL termination, content-based routing, rate limiting, and WAF (Web Application Firewall) functions as integrated services.
Key Takeaway: An L7 load balancer can route traffic based on URL path, HTTP headers, cookies, or request body content — enabling canary deployments (10% of traffic to new version), A/B testing, and per-microservice routing that L4 balancers cannot achieve.
L4 Load Balancing: DSR, NAT, and IPVS
L4 load balancing operates on TCP/UDP connection 5-tuples without inspecting application payload. Three architectures dominate. DSR (Direct Server Return): the balancer rewrites the destination MAC address and forwards the packet; the server responds directly to the client (balancer sees only inbound traffic). DSR achieves near line-rate throughput but requires servers and balancer on the same L2 network. NAT (Network Address Translation): the balancer rewrites destination IP/port and routes through itself in both directions — simpler but throughput-limited by return-path processing. IPVS (IP Virtual Server) in the Linux kernel implements high-performance L4 balancing with scheduling algorithms (round-robin, least connections, locality-based, source hashing). L4 balancers use consistent hashing for stateful connection persistence — ensuring the same client always reaches the same server.
L7 Load Balancing and Content-Based Routing
L7 balancers terminate TCP, inspect HTTP/HTTPS headers and bodies, and make routing decisions based on application-layer information. Key L7 capabilities: content-based routing (route /api/* to one pool, /static/* to CDN), header-based routing (route based on Host, User-Agent, custom headers), session persistence (cookie insertion or learning), request/response rewriting (modify headers, rewrite URLs), and health checking (active HTTP GET with expected response validation). Modern L7 balancers (HAProxy, NGINX, Envoy) process 1M+ RPS on commodity hardware.
SSL/TLS Termination and Acceleration
SSL termination at the load balancer offloads CPU-intensive cryptographic operations from backend servers. The balancer decrypts inbound TLS, performs L7 inspection/routing on the plaintext, then optionally re-encrypts (SSL bridging/offloading) toward backends. Hardware acceleration via Intel QAT or dedicated SSL ASICs achieves 50–100 Gbps of TLS throughput. Modern implementations support TLS 1.3 with 0-RTT, mutual TLS (mTLS) for service-to-service authentication, and automated certificate management via ACME (Automatic Certificate Management Environment) with Let's Encrypt integration.
Kubernetes Ingress and Service Mesh
In Kubernetes, the load balancer pattern is implemented at two layers. Ingress Controller (NGINX Ingress, HAProxy Ingress, Traefik) provides north-south L7 routing from external clients to cluster services. Service Mesh (Istio, Linkerd, Consul Connect) provides east-west L7 routing between microservices within the cluster, using sidecar proxies (Envoy) that intercept all pod traffic. Service mesh adds: circuit breaking (stop sending traffic to failing services), retry and timeout policies, traffic splitting (weighted routing for canary/blue-green deployments), fault injection (chaos engineering), and mTLS with automatic certificate rotation. This dual-layer architecture provides comprehensive traffic management from the edge to the individual microservice.
Global Server Load Balancing (GSLB)
GSLB distributes traffic across multiple data centres using DNS-based routing. The GSLB controller monitors site health and responds to DNS queries with the IP of the optimal site based on: geographic proximity (GeoIP — respond with the nearest site), site load/capacity, persistence (return the same site for session continuity), and active/passive failover. GSLB uses DNS CNAME or A-record responses with short TTLs (10–60 seconds) to enable rapid failover. For 5G edge computing, GSLB integrates with the 5GC AF/NEF to influence UPF traffic steering toward the optimal edge site based on UE location.
The load balancer has evolved from a simple traffic distribution appliance to a comprehensive application delivery platform, and its integration into cloud-native and 5G architectures makes it one of the most critical infrastructure components in modern networks.
