Load Balancers

Load balancers are critical components that distribute incoming traffic across multiple servers, ensuring high availability, scalability, and reliability. Understanding the differences between L4 and L7 load balancers is essential for system design.

What is a Load Balancer?

A load balancer acts as a traffic director that sits between clients and servers, distributing incoming requests across multiple backend servers based on various algorithms and health checks.

Key Benefits:

  • • High Availability: Automatic failover when servers fail
  • • Scalability: Add/remove servers without downtime
  • • Performance: Distribute load optimally across servers
  • • Flexibility: Route traffic based on various criteria

L4 vs L7 Load Balancing

OSI Model Context

Layer 7: ApplicationLayer 6: PresentationLayer 5: SessionLayer 4: TransportLayer 3: NetworkLayer 2: Data LinkLayer 1: PhysicalL7 Load BalancerHTTP/HTTPS• Reads headers• Content routing• SSL terminationL4 Load BalancerTCP/UDP• IP:Port based• Connection level• Fast & simpleL7 sees:• URL paths• Headers• Cookies• Request bodyL4 sees:• Source IP:Port• Dest IP:Port• Protocol (TCP/UDP)

Layer 4 (Transport Layer) Load Balancing

L4 Load Balancer - Connection Level

Client192.168.1.10Port: 54321L4 Load BalancerVIP: 10.0.0.100:80Hash(SrcIP:Port)→ Server 2Server 110.0.1.1:8080Connections: 45Server 2 ✓10.0.1.2:8080Connections: 42Server 310.0.1.3:8080Connections: 38TCP SYNForwardConnectionL4 Characteristics:• Works at TCP/UDP level - doesn't inspect application data• Very fast (minimal processing) - just forwards packets• Connection persistence based on client IP:Port• Cannot route based on URL, headers, or content

✅ L4 Advantages

  • • Very high performance (wire speed)
  • • Low latency (minimal processing)
  • • Can handle any TCP/UDP protocol
  • • Simple and reliable
  • • Less CPU intensive

❌ L4 Limitations

  • • No application-level visibility
  • • Cannot route by URL/content
  • • No HTTP header manipulation
  • • Cannot do SSL termination
  • • Limited health check options

Layer 7 (Application Layer) Load Balancing

L7 Load Balancer - Application Aware

ClientHTTP RequestGET /api/usersCookie: session=abcL7 Load Balancer (Reverse Proxy)SSL TerminationRequest Analysis• Path: /api/users• Session: abc → User1Routing Rules/api/* → API Servers/static/* → CDN/* → Web ServersAPI ServersAPI-1API-2 ✓Web ServersWeb-1Web-2Static/CDNCDN Edge ServerHTTPSRoute toAPI-2L7 Features:• Content-based routing (URL, headers, cookies)• SSL/TLS termination and re-encryption• Request/response modification• Advanced health checks (HTTP status, content)

✅ L7 Advantages

  • • Content-based routing flexibility
  • • SSL/TLS termination
  • • HTTP compression & caching
  • • Request/response modification
  • • Advanced health checks
  • • Session persistence via cookies

❌ L7 Limitations

  • • Higher latency (more processing)
  • • More CPU/memory intensive
  • • Limited to HTTP/HTTPS protocols
  • • Complexity in configuration
  • • Becomes bottleneck at scale

When to Use L4 vs L7

Decision Matrix

ScenarioL4L7Reason
High-performance TCP services✅❌L4 has minimal overhead
URL-based routing needed❌✅L7 can inspect HTTP paths
Database connections (MySQL/PostgreSQL)✅❌Non-HTTP protocol
SSL termination required❌✅L7 handles SSL/TLS
Gaming servers (real-time)✅❌Low latency critical
Microservices with different APIs❌✅Route by API endpoint
WebSocket connections✅⚠️L4 better for long-lived connections
A/B testing, canary deployments❌✅Need header/cookie inspection

Load Balancing Algorithms

Common Algorithms

1. Round Robin

Requests distributed sequentially

Request 1 → Server A
Request 2 → Server B
Request 3 → Server C
Request 4 → Server A (repeat)

2. Least Connections

Route to server with fewest active connections

Server A: 10 connections
Server B: 5 connections ← Choose
Server C: 8 connections

3. IP Hash

Consistent routing based on client IP

hash(192.168.1.10) → Server B
hash(192.168.1.11) → Server A
Same IP always → Same server

4. Weighted Round Robin

Distribution based on server capacity

Server A (weight=3): 3 requests
Server B (weight=2): 2 requests
Server C (weight=1): 1 request

Health Checks

Health Check Mechanisms

L4 Health Checks

TCP connection attempts

# Every 5 seconds
TCP SYN → Server:Port
if (SYN-ACK received):
mark_healthy()
else:
mark_unhealthy()

L7 Health Checks

HTTP endpoint monitoring

# Every 5 seconds
GET /health → Server
if (status == 200 &&
body.contains("OK")):
mark_healthy()
else:
mark_unhealthy()

Real-World Architectures

Common Deployment Patterns

Typical Production SetupInternetCDN / DNS Load BalancingL4 Load Balancer (HA Pair)TCP/UDP DistributionL7 LB (API)/api/* routingL7 LB (Web)/* routingL7 LB (WS)/ws/* routingAPI ServersAPI ServersWeb ServersWeb ServersWebSocketWebSocket

Popular Load Balancer Solutions

L4 Load Balancers

  • • HAProxy - High-performance, open-source
  • • NGINX - Can operate at L4 (stream module)
  • • Linux LVS - Kernel-level, extremely fast
  • • AWS NLB - Network Load Balancer
  • • Google Cloud NLB - Network Load Balancing

L7 Load Balancers

  • • NGINX - Popular reverse proxy
  • • HAProxy - Also supports L7
  • • Traefik - Modern, dynamic configuration
  • • AWS ALB - Application Load Balancer
  • • Envoy - Cloud-native, used in service mesh

System Design Use Cases

🎯When to Use L4 vs L7 in System Design▼

🚀 L4 Load Balancer Use Cases

📊 High-Frequency Trading System
Ultra-low latency requirements, TCP connections, no HTTP overhead needed
🎮 Gaming Backend
UDP/TCP game protocols, persistent connections, minimal processing delay
📺 Video Streaming (Netflix CDN)
TCP streams, high bandwidth, simple round-robin distribution
🏦 Banking Core Systems
Proprietary protocols, guaranteed connection persistence
📱 Mobile App Backends
Simple API routing, maximum performance for mobile clients

🧠 L7 Load Balancer Use Cases

🛒 E-commerce Platform (Amazon)
/api/products → Product Service, /api/orders → Order Service
📱 Social Media Platform (Twitter)
User timeline vs trending API, different caching strategies
🎥 Video Platform (YouTube)
/watch → Video servers, /upload → Upload servers, SSL termination
💬 Chat Application (Slack)
WebSocket routing, session affinity, user-based routing
🏥 Healthcare System
Patient data vs appointment scheduling, compliance routing

🏗️ Multi-Layer Architectures (L4 + L7)

🌐 Large Web Applications (Google, Facebook)
L4 for geographic distribution → L7 for service routing → Microservices
☁️ Cloud Platforms (AWS, Azure)
L4 NLB for initial load distribution → L7 ALB for application routing
📦 Container Orchestration (Kubernetes)
L4 for pod distribution → L7 Ingress for HTTP routing and SSL termination

💡 Decision Framework

Choose L4 When:
  • • Performance is critical
  • • Non-HTTP protocols
  • • Simple distribution needed
  • • High connection volume
Choose L7 When:
  • • Need content-based routing
  • • SSL termination required
  • • Microservices architecture
  • • Advanced health checks
Use Both When:
  • • Large-scale applications
  • • Multi-tier architecture
  • • Geographic distribution
  • • Complex routing needs

Key Takeaways

Remember These Points

1.

L4 is about connections - Works at TCP/UDP level, very fast, protocol agnostic

2.

L7 is about content - Understands HTTP/HTTPS, can make intelligent routing decisions

3.

Use L4 when - You need maximum performance, non-HTTP protocols, simple distribution

4.

Use L7 when - You need content routing, SSL termination, HTTP-specific features

5.

Often used together - L4 in front for initial distribution, L7 behind for application routing

6.

Health checks are critical - Remove unhealthy servers from rotation automatically