L4 vs L7 Load Balancers: Understanding Network Layers in Practice

What Is a Load Balancer?

Before knowing L4 vs L7 Load Balancers first we have to understand what is Load Balancer. A Load Balancer sits between clients and your application servers. Instead of allowing users to connect directly to a single server, every request first reaches the load balancer.

It distributes incoming traffic across multiple backend servers, ensuring that no single machine becomes overloaded.

            Users
              │
              ▼
      Load Balancer
        /    |    \
       ▼     ▼     ▼
   Server1 Server2 Server3

Understanding the OSI Layers

The names L4 and L7 come from the OSI Model.

7  Application  ← HTTP, HTTPS, gRPC
6  Presentation
5  Session
4  Transport    ← TCP, UDP
3  Network      ← IP
2  Data Link
1  Physical

An L4 Load Balancer works at the Transport Layer, while an L7 Load Balancer works at the Application Layer. That difference determines how much information each load balancer can understand before forwarding a request.

What each layer can see:

Netflix handles over 400 million hours of video streaming daily. To distribute that traffic, they use BOTH L4 and L7 load balancers in layers. Understanding what each layer can see - and what it cannot - is the key to choosing the right one.

L4 (Transport Layer)         L7 (Application Layer)
========================     ========================
Source IP: 203.0.113.5       Everything L4 sees, PLUS:
Dest IP:   10.0.1.50         URL:    /api/users/42
Source Port: 52431           Method: GET
Dest Port:   443             Headers: Authorization, Cookie
Protocol: TCP/UDP            Body:   {"name": "Alice"}
                             TLS:    can decrypt HTTPS

L4 routes by:                L7 routes by:
  IP + Port (fast, simple)     URL path, headers, cookies
  Cannot read HTTP content     Can rewrite URLs, add headers
  ~10M connections/sec         ~1M requests/sec

L4 Load Balancing: Fast and Simple

An L4 Load Balancer makes routing decisions using IP addresses and port numbers. It doesn't understand HTTP requests, URLs, cookies, or headers. To an L4 load balancer, every request is simply a stream of TCP/UDP packets.

L4 Load Balancer (AWS NLB, HAProxy TCP mode):

  Client ----TCP----> L4 LB ----TCP----> Backend Server 1
                        |------TCP----> Backend Server 2
                        |------TCP----> Backend Server 3

  Decision: "Server 2 has fewest connections, send it there."
  Speed: processes millions of connections/sec
  Cannot: read URLs, set cookies, terminate TLS content

  Best for:
    - Database connection pooling (PostgreSQL, MySQL)
    - gRPC, WebSocket, game servers (non-HTTP protocols)
    - Ultra-high throughput (>100K req/sec)
    - Any protocol on top of TCP/UDP

The load balancer only looks at information like:

• Source IP

• Destination IP

• TCP Port

• UDP Port

It forwards the connection without inspecting the application data. Every HTTPS connection is forwarded to one of the servers based on the balancing algorithm.

The load balancer doesn't know whether the request is for:

/login

or

/products

or

/api/orders

It only knows that it's forwarding TCP traffic.

L7 Load Balancing: Smart and Flexible

An L7 load balancer fully understands HTTP. It terminates the TLS connection, reads the request, and makes intelligent routing decisions.

L7 Load Balancer (AWS ALB, Nginx, Envoy):

  Client --HTTPS--> L7 LB [decrypts TLS, reads HTTP] --> Backend

  Routing rules (Nginx example):
  location /api/ {
      proxy_pass http://api-servers;      # API cluster
  }
  location /static/ {
      proxy_pass http://cdn-origin;       # CDN origin
  }
  location /ws/ {
      proxy_pass http://websocket-servers; # WebSocket cluster
  }

  # A/B testing by header
  if ($http_x_experiment = "new-checkout") {
      proxy_pass http://experiment-servers;
  }

  # Canary deployment: 5% to new version
  upstream api-servers {
      server 10.0.1.1 weight=95;  # v2.0 (stable)
      server 10.0.1.2 weight=5;   # v2.1 (canary)
  }

Instead of looking only at IP addresses, it can inspect:

• URLs

• HTTP Methods

• Headers

• Cookies

• Host Names

• Query Parameters

This allows it to make intelligent routing decisions. Imagine your application serves three different workloads.

example.com/api
example.com/images
example.com/static

An L7 load balancer can inspect the URL and route requests accordingly.

     Client
       │
       ▼
L7 Load Balancer
/api     → API Servers
/images  → Image Servers
/static  → CDN Servers

The client sees one website, while the load balancer intelligently routes requests to different backend services.

L4 vs L7 Comparison

Feature              L4 (Transport)       L7 (Application)
-------------------  -------------------  -----------------------
Sees HTTP content    No                   Yes
URL-based routing    No                   Yes
TLS termination      No (passthrough)     Yes (decrypts + re-encrypts)
Health checks        TCP connect only     HTTP GET /health
Sticky sessions      IP hash only         Cookie-based
Performance          ~10M conn/sec        ~1M req/sec
Latency overhead     ~0.1ms               ~1-5ms
Use cases            TCP, UDP, databases  HTTP APIs, web apps
-------------------  -------------------  -----------------------
AWS product          NLB                  ALB
Open source          HAProxy (TCP mode)   Nginx, Envoy, HAProxy

Real-World Examples

L4 Load Balancer                                             L7 Load Balancer

Best suited for:                                             Best suited for:  
  MySQL                                                        REST APIs
  PostgreSQL                                                   GraphQL
  Redis                                                        E-commerce websites
  Kafka                                                        SaaS platforms
  Multiplayer games                                            Kubernetes Ingress 
  DNS                                                          Microservices
  MQTT                                                       These applications need intelligent request routing.
These protocols don't require HTTP awareness.              

Layered Architecture: Use Both

Production architecture (common pattern):

  Internet
     |
  [L4 NLB]  <-- distributes raw TCP across L7 instances
     |
  +--+--+
  |     |
  [L7]  [L7]  <-- each L7 does smart HTTP routing
  |     |
  +--+--+--+--+
  |  |  |  |  |
  API servers, static servers, WebSocket servers

  Why both?
  - L4 distributes load across L7 instances (HA for the LBs)
  - L7 does content-based routing (URL, headers, cookies)
  - L4 handles the raw throughput, L7 handles the intelligence

Interview Tip

When an interviewer asks about load balancing, specify the layer: 'For our HTTP API, I would use an L7 load balancer like AWS ALB for content-based routing and TLS termination. For our database connection pool, I would use an L4 load balancer like AWS NLB because we just need to distribute TCP connections. In high-traffic systems, I would layer L4 in front of L7 to make the load balancers themselves highly available.'

Key Takeaway

L4 load balancers are fast because they only look at IP/port. L7 load balancers are smart because they understand HTTP. Most web applications use L7 for content-based routing and TLS termination. High-performance systems layer L4 in front for raw throughput.