Load balancing in Layer 4 vs Layer 7 with HAPROXY Examples

Load balancing in Layer 4 vs Layer 7 with HAPROXY Examples

By At June 14, 2025 0




Here’s a FAANG-level deep dive into Layer 4 (L4) and Layer 7 (L7) Load Balancers, covering:

  • OSI layer concepts

  • Real-world usage

  • Design trade-offs

  • Use cases in distributed systems

  • Interview-level comparisons

  • Visual diagrams

  • Debugging & metrics

  • Questions for interviews

🔹1. OSI Context & Basics

Layer

Load Balancer Type

Works With

Key Decision Criteria

L4

Transport Layer

TCP/UDP

IP + Port + Protocol

L7

Application Layer

HTTP, gRPC, WebSocket

URL path, headers, cookies, content

🔹2. Layer 4 Load Balancer (L4)

🧠 Concept:
 Operates at the transport layer (TCP/UDP). It forwards packets without parsing application data.

🔧 Mechanism:

  • Load balancing happens based on:

    • Source IP

    • Destination IP

    • Port

    • Protocol (TCP/UDP)

  • Uses techniques like round-robin, least connections, or IP hash.

✅ Pros:

  • Fast (packet-level routing, minimal overhead)

  • Protocol-agnostic (works for non-HTTP traffic like FTP, SMTP)

  • Efficient for backend services like databases, gRPC, etc.

❌ Cons:

  • No application-level routing

  • Cannot do SSL termination or cookie-based session stickiness

📦 Example Tools:

  • Linux IPVS

  • AWS NLB (Network Load Balancer)

  • HAProxy (in TCP mode)

  • Envoy (L4 config)

🧪 FAANG Use Case:
 Database proxy balancing between primary/replica nodes using IP-based routing for high throughput.

🔹3. Layer 7 Load Balancer (L7)

🧠 Concept:
 Operates at the application layer. Understands HTTP headers, paths, cookies, etc.

🔧 Mechanism:

  • Reads HTTP headers, query params, and content

  • Makes smart decisions like:

    • /api/* → Microservice A

    • /static/* → CDN/Bucket

  • Handles SSL termination, compression, and caching

✅ Pros:

  • Fine-grained routing

  • Better observability (status codes, user agents)

  • Can enforce security (e.g., Web Application Firewall)

❌ Cons:

  • Higher CPU/memory usage (parsing full payloads)

  • Slightly higher latency than L4

📦 Example Tools:

  • NGINX (HTTP reverse proxy)

  • Envoy Proxy (in L7 mode)

  • AWS ALB (Application Load Balancer)

  • GCP HTTP(S) Load Balancer

  • Istio Ingress Gateway

🧪 FAANG Use Case:
 Instagram service routes:

  • /feed → FeedService

  • /story → StoryService

  • /media/* → Media CDN

🔹4. Visual Comparison

        ┌──────────────┐        ┌─────────────────────────┐
         │  Client      ├───────►  L4 Load Balancer        │
         └──────────────┘        │  (IP:PORT based routing)│
                                 └──────┬──────┬────────────┘
                                        │      │
                              ┌─────────▼──┐ ┌─▼────────────┐
                              │ Service A  │ │ Service B    │
                              └────────────┘ └──────────────┘

        ┌──────────────┐        ┌─────────────────────────────┐
         │  Client      ├───────►  L7 Load Balancer            │
         └──────────────┘        │  (HTTP routing based on URI)│
                                 └────┬────────┬───────────────┘
                                      │        │
                          ┌───────────▼──┐ ┌───▼────────────┐
                          │ /feed → Feed │ │ /story → Story │
                          └──────────────┘ └────────────────┘


🔹5. When to Use What?

Scenario

Choose

Why

DB or non-HTTP traffic

L4

Less overhead, protocol agnostic

HTTP API gateway

L7

Smart routing, observability

gRPC microservices

L4 or L7

L7 for routing, L4 for performance

CDN-style static content

L7

Path-based routing, caching

Internal service mesh

L4 (sidecar) + L7 (Envoy/Istio)

Combined benefits

🔹6. FAANG-Level Interview Questions

🔸 Conceptual

  1. How does a Layer 4 Load Balancer differ from Layer 7 in TLS termination?

  2. Which one would you choose to route based on a cookie? Why?

  3. Explain L4 and L7 behavior during a long-polling WebSocket connection.

  4. What happens if the backend server responds with a 5xx? How does L4 vs L7 handle retries?

  5. What are the limitations of a L7 LB in Kubernetes Ingress?

🔸 Design/Scenario-Based

  1. Design an HAProxy-based solution for 1000 HTTP microservices.

  2. You observe latency spikes in your L7 load balancer. Walk through debugging steps.

  3. In your system, some requests are non-idempotent. Should the LB retry them?

  4. Route traffic between old and new app versions (canary deployment): L4 or L7?

🔹7. Debugging Metrics & Tools

Tool

Purpose

L4/L7

tcpdump

Packet inspection

L4

iptables

IP-level routing

L4

nginx -V

Config check

L7

Prometheus + Grafana

Metric collection (5xx, latency, retries)

L7

strace/lsof

Check open sockets

L4/L7

Jaeger/Zipkin

Distributed tracing

L7

🔹8. Advanced Concepts

Concept

L4

L7

TLS passthrough

✅ Supported

❌ (usually terminates)

Sticky sessions

IP Hash

Cookies

Health checks

TCP-level ping

HTTP status check

Global load balancing

Via DNS (GeoIP)

Smart routing (GCP/AWS)

Service mesh integration

Limited

Native (e.g., Istio)

🔹9. Summary Table

Feature

Layer 4

Layer 7

Protocols

TCP/UDP

HTTP, gRPC, WebSocket

Routing logic

IP + Port

URL path, headers, cookies

SSL termination

❌ (Pass-through)

✅ (Decrypt and inspect)

Observability

Low (binary)

High (status codes, logs)

Performance

High

Slightly lower (due to parsing)

Cost

Cheaper

Slightly more expensive

🔹10. Bonus: Service Mesh View

Service meshes like Istio or Linkerd use L4 sidecars and L7 proxies for complete routing and policy control:



App Pod
 ┌────────────┐
 │  App       │
 └────┬───────┘
      │
 ┌────▼────┐
 │ Sidecar │ (Envoy: L4 + L7)
 └─────────┘


Want Hands-On? 🧪

You can simulate both L4 & L7 locally:

L4: TCP Proxy with HAProxy

listen app
  bind *:80
  mode tcp
  balance roundrobin
  server s1 10.0.0.1:80
  server s2 10.0.0.2:80


L7: HTTP Routing with NGINX

location /api {
  proxy_pass http://api-service;
}
location /static {
  proxy_pass http://cdn-service;
}

Can Nginx be used as L4 Loadbalancer

NGINX can be used as a Layer 4 Load Balancer, but only NGINX Plus supports native L4 (TCP/UDP) load balancing fully.

Open Source NGINX (OSS) has some L4 capabilities but they are limited.

🔹 Layer 4 Support in NGINX

Feature

NGINX OSS

NGINX Plus

TCP load balancing

⚠️ Limited (via stream block)

✅ Full support

UDP load balancing

⚠️ Limited

✅ Full support

Health checks for TCP/UDP

❌ (manual only)

✅ Active checks

TLS passthrough (no decryption)

✅ (via stream)

✅

Session persistence (L4)

❌

✅ via IP hash or cookies

🔹 L4 Load Balancing in NGINX OSS

NGINX OSS uses the stream module to support basic L4 proxying for TCP/UDP.

🔸 Example: TCP Load Balancing (e.g., MySQL)

stream {
    upstream backend {
        server 10.0.0.1:3306;
        server 10.0.0.2:3306;
    }

    server {
        listen 3306;
        proxy_pass backend;
    }
}

🔸 Example: Load Balancing Redis (TCP)
stream {
    upstream redis_upstream {
        server redis1:6379;
        server redis2:6379;
    }

    server {
        listen 6379;
        proxy_pass redis_upstream;
    }
}


🔧 You need to enable the stream module in OSS if it's not compiled.

🔹 Limitations in Open Source NGINX

  • ❌ No active TCP/UDP health checks

  • ❌ No session affinity at L4

  • ❌ No traffic splitting or weighted backends

  • ❌ No observability metrics per TCP/UDP connection

  • ❌ No automatic failover — just round-robin

🔹 NGINX Plus for Full L4 LB

NGINX Plus adds:

  • ✅ Native health checks for TCP/UDP

  • ✅ Live activity monitoring dashboard

  • ✅ Session persistence via IP

  • ✅ Fine-grained control on load balancing algorithms

Example with NGINX Plus:

stream {
    upstream db_backend {
        zone db_backend 64k;
        server db1.example.com:5432 max_fails=3 fail_timeout=30s;
        server db2.example.com:5432;
    }

    server {
        listen 5432;
        proxy_pass db_backend;
    }
}


🔹 Use Cases for NGINX L4 LB

Protocol

Use Case

Notes

MySQL

Proxy reads to replicas

Use read/write split manually

Redis

Distribute cache workload

Ensure client understands sharding

MQTT

IoT protocol over TCP

Low overhead, high concurrency

SMTP

Email relaying

Session-based, L4 works well

gRPC

L4 if you don't need inspection

Or go with Envoy for L7

🔹 NGINX as L4 in Kubernetes?

  • Ingress: NGINX Ingress Controller (official) works at L7 (HTTP).

  • For L4, you'd use kube-proxy, MetalLB, or a sidecar like Envoy instead.

However, NGINX can run in a pod with stream config to act as a L4 proxy in-cluster.

🔹 Summary

Category

NGINX OSS (Free)

NGINX Plus (Paid)

L4 TCP Load Balancing

✅ Basic via stream

✅ Full features

UDP Support

✅ Basic

✅ Enhanced

Active Health Checks

❌

✅

TLS Passthrough

✅

✅

Ideal for gRPC, DB

✅

✅

✅ Recommendation

  • Use NGINX OSS for simple TCP load balancing.

  • Use NGINX Plus if you need:

    • Active health checks

    • Monitoring

    • Advanced failover & session handling

  • Use Envoy or HAProxy if you want powerful open-source L4/L7 hybrid alternatives.


Distributed by Gooyaabi Templates | Designed by OddThemes