System Design HLDLayer 4 vs Layer 7 Load Balancing

Layer 4 vs Layer 7 Load Balancing

LevelIntermediate

Duration75 mins

TopicLayer 4 vs Layer 7 Load Balancing

4 / 5

Use Cases for Each Layer

Pattern Matching to Real-World Scenarios

Theory becomes actionable through concrete examples. While understanding the mechanics of Layer 4 and Layer 7 load balancing is essential, knowing when to apply each approach—recognizing the patterns in your own requirements—is where engineering judgment materializes.

This page presents comprehensive use cases for both layers, drawn from production systems across industries. By studying these patterns, you'll develop the intuition to select the right approach for your specific needs.

What You Will Learn

By the end of this page, you will recognize specific scenarios where Layer 4 is essential (gaming, databases, high-frequency trading), scenarios where Layer 7 is required (web applications, microservices, API gateways), and hybrid architectures that combine both layers for optimal results.

Layer 4 Use Case: Online Gaming and Real-Time Multiplayer

Online gaming represents one of the clearest cases for Layer 4 load balancing. The combination of latency sensitivity, custom protocols, and high connection volumes makes Layer 4 essential.

The Gaming Architecture Challenge

Multiplayer games have unique requirements:

Ultra-low latency: 10-50ms round-trip expected; 100ms+ feels laggy
High update frequency: 20-128 updates per second per player
Custom protocols: Often proprietary UDP-based protocols optimized for specific games
Long-lived connections: Players connected for hours at a time
Connection stickiness: Player must remain on the same game server instance

Gaming Protocol Characteristics
Game Type	Protocol	Update Rate	Latency Tolerance
First-Person Shooter	UDP custom	64-128 Hz	< 30ms
Battle Royale	UDP custom	20-60 Hz	< 50ms
MOBA	TCP/UDP hybrid	30-60 Hz	< 80ms
MMO	TCP custom	10-30 Hz	< 150ms
Turn-based	TCP/HTTP	On-demand	< 500ms

Why Layer 4 Is Essential for Gaming

Protocol support: Games use custom UDP protocols that Layer 7 proxies cannot understand or parse
Latency preservation: Every millisecond of added latency degrades player experience
Connection persistence: Once matched to a server, the player must stay on that exact instance
Throughput efficiency: With millions of packets/second, Layer 4's efficiency matters

Gaming Load Balancing Architecture

Typical architecture:

Global DNS/Anycast: Route players to nearest region
Layer 4 load balancer: Distribute to matchmaking service
Matchmaking service: Assigns player to specific game server
Direct connection: Player connects directly to assigned server (bypassing LB for gameplay)

The load balancer handles initial connection and matchmaking; gameplay traffic often bypasses the LB entirely to minimize latency.

gaming-lb-architecture.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Gaming Infrastructure Load Balancing Pattern
=============================================
 
Phase 1: Login and Matchmaking (Through LB)
                                    
  Player → [DNS/Anycast] → [L4 LB] → [Login Service]
                              ↓
                        [Matchmaking Service]
                              ↓
                        Assigns server-1.us-east.game.com
 
Phase 2: Gameplay (Direct Connection)
 
  Player ←─────── UDP direct ───────→ Game Server Instance
  
  Note: L4 LB may still handle:
    - Friend list / social features (HTTP)
    - Leaderboards (HTTP)  
    - In-game store (HTTPS)
    - Voice chat signaling (UDP)
 
Scale Numbers:
  - Peak: 10M+ concurrent connections
  - Update rate: 64 packets/sec/player = 640M pps
  - Latency budget: < 5ms for LB hop

Hybrid Pattern: HTTP + UDP

Modern games often split traffic: HTTP/HTTPS through Layer 7 for login, store, and social features; UDP through Layer 4 (or direct) for gameplay. This combines Layer 7's benefits for web-style traffic with Layer 4's performance for real-time gameplay.

Layer 4 Use Case: Database Connection Pooling and Load Balancing

Databases and stateful services require Layer 4 load balancing due to their wire protocols, connection semantics, and performance requirements.

Database Wire Protocols

Databases use specialized binary protocols:

PostgreSQL: Custom binary protocol over TCP (port 5432)
MySQL: Custom binary protocol over TCP (port 3306)
MongoDB: BSON over custom protocol (port 27017)
Redis: RESP protocol over TCP (port 6379)
Cassandra: CQL binary protocol (port 9042)

These protocols are not HTTP; Layer 7 proxies cannot parse them. Layer 4 is the only option for generic database load balancing.

Database Load Balancing Patterns
Database	Protocol	LB Strategy	Key Consideration
PostgreSQL	libpq binary	L4 to read replicas	Connection pooling (PgBouncer)
MySQL	MySQL protocol	L4 with ProxySQL	Read/write splitting
Redis	RESP	L4 to replicas or cluster	Cluster mode: no LB needed
MongoDB	BSON	L4 or built-in driver	Driver handles replica set
Cassandra	CQL	Client-side or L4	Token-aware routing preferred

Read Replica Load Balancing

The most common database LB pattern: distributing read queries across multiple replicas:

Write traffic → Primary/master database (single instance)
Read traffic → Load balanced across replicas

Layer 4 load balancing for read replicas:

Distributes connections to available replicas
Health checks via TCP connect or custom script
Removes unhealthy replicas from rotation
Session persistence often required for transactions

Connection Pooling

Database connections are expensive (memory, authentication, TLS). Architectures typically use:

Server-side poolers: PgBouncer (PostgreSQL), ProxySQL (MySQL)
Layer 4 LB to pooler: Distribute application connections to pooler instances
Pooler to database: Multiplexed, persistent connections

The Layer 4 LB distributes application connections; the pooler manages database connections.

Converting Mermaid diagram...

Protocol-Aware Database Proxies

Some database proxies (ProxySQL, Vitess, CockroachDB load balancer) understand their specific protocol at Layer 7. They can parse queries, route reads vs. writes, and implement sophisticated logic. These are specialized Layer 7 proxies for specific databases—not generic HTTP Layer 7 load balancers.

Layer 4 Use Case: High-Frequency Trading and Financial Systems

Financial trading systems represent the extreme end of the latency spectrum. Here, Layer 4's microsecond overhead advantage over Layer 7's millisecond overhead translates directly to competitive advantage and money.

The Latency Arms Race

In high-frequency trading (HFT):

Speed = profit: Being 1ms faster than competitors means executing better trades
Every component matters: Network cards, switches, cables, and load balancers are all optimized
Microseconds are measured: Systems track latency in microseconds, not milliseconds
Hardware acceleration is common: FPGAs, custom ASICs, kernel bypass

Financial Trading Latency Budgets
System Tier	Total Latency Budget	LB Allocation	LB Technology
Ultra-low latency HFT	< 10 µs	< 1 µs	FPGA/ASIC, no LB
Low-latency trading	< 100 µs	< 5 µs	DPDK/XDP, L4 only
Market making	< 1 ms	< 50 µs	L4 software
Execution services	< 10 ms	< 500 µs	L4 or L7
Retail trading	< 100 ms	< 5 ms	L7 acceptable

Financial Protocol Requirements

Financial systems use specialized protocols:

FIX (Financial Information eXchange): Text-based protocol over TCP
FAST (FIX Adapted for Streaming): Binary, compressed market data
ITCH/OUCH: NASDAQ proprietary order entry protocols
Binary Exchange Protocols: Exchange-specific order and data protocols

These protocols require Layer 4 handling—they're not HTTP.

Architecture Patterns

Market data distribution:

Exchange feed → Feed handler
L4 LB or multicast → Multiple consumers
Consumers process independently

Order routing:

Trading engine → L4 LB
LB → Exchange gateway (primary or backup)
Session persistence: Same gateway for cancel/modify

Cross-datacenter:

Active-active in multiple locations
L4 LB with latency-based routing
Automatic failover < 100µs

trading-latency-components.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Ultra-Low Latency Trading System Component Breakdown
====================================================
 
Total round-trip budget: 50 microseconds
 
Component Breakdown:
--------------------
Network (fiber, switch):    15 µs  (30%)
NIC processing:              3 µs  ( 6%)
Kernel network stack:        5 µs  (10%)  ← eliminated with bypass
Load balancer:               5 µs  (10%)  ← L4 only, kernel bypass
Application logic:          20 µs  (40%)
Response path:               2 µs  ( 4%)
 
With Optimization:
------------------
FPGA NIC (no kernel):        1 µs
No load balancer (direct):   0 µs
Co-located exchange:         5 µs wire
------------------------------------
Achievable:                < 10 µs round-trip
 
Key: Every component that touches packets is
     measured and optimized. Layer 7 (adding 1-5ms)
     would consume 20-100x the entire budget.

When Load Balancers Are Eliminated

In the most latency-sensitive trading scenarios, load balancers are eliminated entirely. Trading engines connect directly to exchange gateways with redundant paths. Failover is handled at the application or NIC level, not by an intermediary. This is the extreme case where even Layer 4's minimal overhead is unacceptable.

Layer 7 Use Case: Web Applications and APIs

Web applications and REST/GraphQL APIs are the primary domain for Layer 7 load balancing. The HTTP protocol's richness and the need for content-based routing make Layer 7 essential.

Why Layer 7 Is Essential for Web

Virtual hosting: Multiple domains on single IP
Path-based routing: /api and /web to different backends
TLS termination: Centralized certificate management
HTTP rewriting: Headers, URLs, redirects
Caching: Edge caching of static content
Compression: Response compression
Security: WAF, rate limiting, authentication

Typical Web Application Routing

•/ → Frontend server (React/Vue/Angular)
•/api/ → API backend cluster
•/static/ → CDN or static file server
•/admin/ → Admin panel (restricted network)
•/health → Health check response
•/ws/ → WebSocket server cluster

Layer 7 Benefits for Web

•Single entry point for all services
•Centralized TLS certificate management
•Request logging and metrics
•A/B testing and canary deployments
•Rate limiting per endpoint
•WAF protection at edge

API Gateway Pattern

Layer 7 load balancers often implement the API Gateway pattern:

Single entry point: All API traffic through one endpoint
Authentication: Validate tokens at the gateway
Rate limiting: Enforce quotas per client/endpoint
Request transformation: Add headers, rewrite paths
Response aggregation: Combine multiple backend calls
Caching: Cache responses at the edge

E-commerce Example

A typical e-commerce platform routing configuration:

ecommerce-routing.yaml
YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
# E-commerce Layer 7 Routing Configuration
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ecommerce-ingress
  annotations:
    nginx.ingress.kubernetes.io/rate-limit: "100"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  tls:
    - hosts: [shop.example.com, api.example.com]
      secretName: ecommerce-tls
  rules:
    # Main website
    - host: shop.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend
                port: {number: 80}
          - path: /checkout
            pathType: Prefix
            backend:
              service:
                name: checkout-service
                port: {number: 80}
    
    # API endpoints
    - host: api.example.com
      http:
        paths:
          - path: /v1/products
            pathType: Prefix
            backend:
              service:
                name: product-service
                port: {number: 8080}
          - path: /v1/orders
            pathType: Prefix
            backend:
              service:
                name: order-service
                port: {number: 8080}
          - path: /v1/users
            pathType: Prefix
            backend:
              service:
                name: user-service
                port: {number: 8080}

Web Performance Context

For typical web applications, backend processing (50-500ms) dwarfs Layer 7 overhead (2-5ms). The operational benefits of Layer 7—observability, routing flexibility, security—provide immense value with negligible performance impact relative to the overall request lifecycle.

Layer 7 Use Case: Microservices and Service Mesh

Microservices architectures are fundamentally dependent on Layer 7 load balancing. The need to route requests to the appropriate service based on path, header, or content makes Layer 7 essential.

The Microservices Routing Challenge

In a microservices architecture:

Many services: Tens to thousands of independent services
Single entry point expected: Users expect one domain, not service-1.example.com, service-2.example.com
Dynamic discovery: Services scale up/down, change locations
Sophisticated routing: Version routing, canary deployments, A/B testing

Layer 4 cannot solve this problem—it has no concept of HTTP paths or headers.

North-South vs East-West Traffic

North-South (external entry):

Client → Ingress Layer 7 LB → Services
TLS termination, external routing
API gateway functionality

East-West (service-to-service):

Service A → Sidecar/Service Mesh → Service B
Internal Layer 7 routing
mTLS, observability, retry logic

Converting Mermaid diagram...

Service Mesh and Layer 7

Service meshes (Istio, Linkerd, Consul Connect) implement Layer 7 load balancing through sidecar proxies:

Capabilities:

Automatic mTLS: Encrypted service-to-service communication
Intelligent routing: Version-based, header-based, percentage-based splits
Resilience: Circuit breakers, retries, timeouts per route
Observability: Metrics, logs, and traces for every request
Policy enforcement: Rate limiting, authorization rules

Trade-off:

Each proxy adds ~1-5ms latency per hop
For a request traversing 5 services: 5-25ms added latency
Usually acceptable; for latency-critical paths, direct connections may be needed

Service Mesh Layer 7 Capabilities
Feature	Without Service Mesh	With Service Mesh
Service discovery	Manual/DNS	Automatic, dynamic
Load balancing	Client library or L4	L7 with intelligent routing
mTLS	Manual certificate management	Automatic, transparent
Observability	Instrument each service	Automatic per-request metrics
Traffic splitting	Application code	Configuration-driven
Circuit breaking	Library per service	Centralized policy

When to Adopt Service Mesh

Service mesh is powerful but adds complexity and overhead. It's typically worthwhile when: you have 20+ services, need consistent security/observability across services, want configuration-driven traffic management, or require mTLS for compliance. For smaller deployments, a simple ingress controller may suffice.

Layer 7 Use Case: Security, Authentication, and WAF

Security is often the decisive factor for Layer 7 adoption. Many security functions are inherently Layer 7 operations—they require understanding the application protocol.

Web Application Firewall (WAF)

WAFs protect against application-layer attacks:

SQL Injection: Detect malicious SQL patterns in parameters
Cross-Site Scripting (XSS): Block script injection attempts
Path traversal: Prevent ../../../etc/passwd attacks
Request smuggling: Detect malformed HTTP requests
Protocol violations: Reject invalid HTTP

Layer 4 cannot provide this protection—it doesn't understand HTTP.

OWASP Top 10 and Layer 7 Protection

•A01:2021 Broken Access Control → Path-based authorization at LB
•A02:2021 Cryptographic Failures → TLS termination with modern ciphers
•A03:2021 Injection → WAF pattern matching, input validation
•A04:2021 Insecure Design → Rate limiting, circuit breaking
•A05:2021 Security Misconfiguration → Security headers injection
•A07:2021 Identification Failures → Centralized authentication at gateway
•A09:2021 Logging Failures → Comprehensive request logging at L7

Centralized Authentication

Layer 7 load balancers can offload authentication from backends:

Token validation:

Request arrives with Authorization header
LB validates JWT signature and claims
If valid: Add X-User-ID header, forward to backend
If invalid: Return 401 immediately

Benefits:

Backends don't need authentication logic
Consistent enforcement across all services
Centralized token management (key rotation)
Reduced backend load (invalid requests rejected at edge)

Rate Limiting and DDoS Protection

Layer 7 enables sophisticated rate limiting:

Per client: Limit by IP, user ID, API key
Per endpoint: Different limits for /search vs /checkout
Adaptive: Dynamic limits based on system load
Distributed: Synchronized limits across LB instances

For DDoS, Layer 7 can:

Challenge suspected bots (CAPTCHA, JavaScript challenges)
Block by request pattern (not just IP)
Absorb application-layer attacks (HTTP floods)

security-configuration.yaml
YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# Layer 7 Security Configuration (Envoy-style)
http_filters:
  # JWT Authentication
  - name: envoy.filters.http.jwt_authn
    typed_config:
      providers:
        auth0:
          issuer: "https://example.auth0.com/"
          audiences: ["api.example.com"]
          remote_jwks:
            http_uri:
              uri: "https://example.auth0.com/.well-known/jwks.json"
      rules:
        - match: {prefix: "/api/"}
          requires:
            provider_name: auth0
        - match: {prefix: "/public/"}  # No auth required
  
  # Rate Limiting
  - name: envoy.filters.http.ratelimit
    typed_config:
      domain: api_rate_limit
      rate_limit_service:
        grpc_service:
          envoy_grpc:
            cluster_name: rate_limit_cluster
      descriptors:
        - entries:
            - key: user_id
              value: "%REQ(X-User-ID)%"
        - entries:
            - key: path
              value: "%REQ(:path)%"
  
  # WAF (ModSecurity rules)
  - name: envoy.filters.http.wasm
    typed_config:
      vm_config:
        code:
          local: {filename: "/etc/envoy/wasm/coraza-waf.wasm"}

Defense in Depth

Layer 7 security at the load balancer is one layer of defense, not the only layer. Continue to implement validation in backends, use prepared statements for SQL, and follow secure coding practices. The load balancer provides a valuable first line of defense and consistent policy enforcement.

Hybrid Architectures: Combining Layer 4 and Layer 7

Production systems rarely use Layer 4 or Layer 7 exclusively. Hybrid architectures leverage both layers strategically, optimizing for their respective strengths.

Common Hybrid Patterns

Pattern 1: Layer 4 in Front of Layer 7

The most common hybrid: Layer 4 handles connection distribution; Layer 7 handles application routing.

Internet → L4 LB → L7 LBs → Services

Benefits:

L4 provides health checking and failover for L7 instances
L4 can do basic DDoS mitigation (SYN flood protection)
L7 can be scaled horizontally behind L4
L4 is stateless (easy HA); L7 maintains application context

Example: AWS architecture with NLB in front of ALB (common for WebSocket + HTTP).

Converting Mermaid diagram...

Pattern 2: Split by Protocol

Different protocols get different treatment:

HTTP/HTTPS → L7 LB → Web/API services
TCP/UDP (gaming, DB) → L4 LB → Specialized services

Example: Gaming company with HTTP APIs through L7, game traffic through L4.

Pattern 3: Split by Sensitivity

Latency-sensitive traffic bypasses Layer 7:

Critical path → L4 or direct
General traffic → L7 with full features

Example: Trading platform with order execution on L4, everything else on L7.

Pattern 4: TLS Passthrough + HTTP Termination

External TLS → L7 terminates → Backend
Internal TLS (mTLS) → L4 passthrough → Backend terminates

Example: Ingress terminates external TLS; internal mTLS passes through.

Hybrid Architecture Decision Matrix
Traffic Type	Layer	Rationale
Public HTTP/HTTPS	L7	Routing, TLS, WAF, caching
Internal HTTP	L7 (service mesh) or L4	Observability vs simplicity
Database connections	L4	Binary protocol, performance
WebSocket	L7 or L4	L7 for routing; L4 for simplicity
Gaming UDP	L4	Custom protocol, latency
gRPC	L7 (gRPC-aware)	Stream routing, health checks

Complexity vs Capability

Each layer added increases operational complexity. A simple L7-only architecture may be preferable to a complex hybrid if the advanced capabilities aren't needed. Add layers only when they provide concrete value that justifies their operational cost.

Summary: Use Cases for Each Layer

Understanding use cases transforms theoretical knowledge into practical decision-making. The choice between Layer 4 and Layer 7—or a hybrid approach—depends on your specific protocol, latency requirements, routing needs, and operational priorities.

Key Takeaways

•Gaming requires Layer 4: Custom UDP protocols, microsecond-sensitive latency, and high packet rates demand Layer 4
•Databases require Layer 4: Binary protocols that Layer 7 cannot parse; often combined with protocol-aware proxies
•Trading systems minimize layers: Extreme latency sensitivity may eliminate load balancers entirely
•Web applications thrive on Layer 7: Path routing, TLS termination, observability, and security features are essential
•Microservices require Layer 7: Service mesh and intelligent routing are foundational to the architecture
•Security features are Layer 7: WAF, authentication, and sophisticated rate limiting need protocol awareness
•Hybrid architectures are common: Layer 4 in front of Layer 7, split by protocol, or split by sensitivity

What's next:

With use cases established, the final page explores hybrid approaches in depth—architectural patterns that strategically combine Layer 4 and Layer 7 for optimal performance, flexibility, and operational efficiency.

Page Complete

You can now pattern-match your requirements to established use cases. Whether you're building a gaming platform, a microservices architecture, a trading system, or a web application, you know which layer—or combination—best serves your needs.

4 / 5

Loading learning content...

System Design HLDLayer 4 vs Layer 7 Load Balancing

Layer 4 vs Layer 7 Load Balancing

LevelIntermediate

Duration75 mins

TopicLayer 4 vs Layer 7 Load Balancing

4 / 5

Use Cases for Each Layer

Pattern Matching to Real-World Scenarios

What You Will Learn

Layer 4 Use Case: Online Gaming and Real-Time Multiplayer

Online gaming represents one of the clearest cases for Layer 4 load balancing. The combination of latency sensitivity, custom protocols, and high connection volumes makes Layer 4 essential.

The Gaming Architecture Challenge

Multiplayer games have unique requirements:

Ultra-low latency: 10-50ms round-trip expected; 100ms+ feels laggy
High update frequency: 20-128 updates per second per player
Custom protocols: Often proprietary UDP-based protocols optimized for specific games
Long-lived connections: Players connected for hours at a time
Connection stickiness: Player must remain on the same game server instance

Gaming Protocol Characteristics
Game Type	Protocol	Update Rate	Latency Tolerance
First-Person Shooter	UDP custom	64-128 Hz	< 30ms
Battle Royale	UDP custom	20-60 Hz	< 50ms
MOBA	TCP/UDP hybrid	30-60 Hz	< 80ms
MMO	TCP custom	10-30 Hz	< 150ms
Turn-based	TCP/HTTP	On-demand	< 500ms

Why Layer 4 Is Essential for Gaming

Protocol support: Games use custom UDP protocols that Layer 7 proxies cannot understand or parse
Latency preservation: Every millisecond of added latency degrades player experience
Connection persistence: Once matched to a server, the player must stay on that exact instance
Throughput efficiency: With millions of packets/second, Layer 4's efficiency matters

Gaming Load Balancing Architecture

Typical architecture:

Global DNS/Anycast: Route players to nearest region
Layer 4 load balancer: Distribute to matchmaking service
Matchmaking service: Assigns player to specific game server
Direct connection: Player connects directly to assigned server (bypassing LB for gameplay)

The load balancer handles initial connection and matchmaking; gameplay traffic often bypasses the LB entirely to minimize latency.

gaming-lb-architecture.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Gaming Infrastructure Load Balancing Pattern
=============================================
 
Phase 1: Login and Matchmaking (Through LB)
                                    
  Player → [DNS/Anycast] → [L4 LB] → [Login Service]
                              ↓
                        [Matchmaking Service]
                              ↓
                        Assigns server-1.us-east.game.com
 
Phase 2: Gameplay (Direct Connection)
 
  Player ←─────── UDP direct ───────→ Game Server Instance
  
  Note: L4 LB may still handle:
    - Friend list / social features (HTTP)
    - Leaderboards (HTTP)  
    - In-game store (HTTPS)
    - Voice chat signaling (UDP)
 
Scale Numbers:
  - Peak: 10M+ concurrent connections
  - Update rate: 64 packets/sec/player = 640M pps
  - Latency budget: < 5ms for LB hop

Hybrid Pattern: HTTP + UDP

Layer 4 Use Case: Database Connection Pooling and Load Balancing

Databases and stateful services require Layer 4 load balancing due to their wire protocols, connection semantics, and performance requirements.

Database Wire Protocols

Databases use specialized binary protocols:

PostgreSQL: Custom binary protocol over TCP (port 5432)
MySQL: Custom binary protocol over TCP (port 3306)
MongoDB: BSON over custom protocol (port 27017)
Redis: RESP protocol over TCP (port 6379)
Cassandra: CQL binary protocol (port 9042)

These protocols are not HTTP; Layer 7 proxies cannot parse them. Layer 4 is the only option for generic database load balancing.

Database Load Balancing Patterns
Database	Protocol	LB Strategy	Key Consideration
PostgreSQL	libpq binary	L4 to read replicas	Connection pooling (PgBouncer)
MySQL	MySQL protocol	L4 with ProxySQL	Read/write splitting
Redis	RESP	L4 to replicas or cluster	Cluster mode: no LB needed
MongoDB	BSON	L4 or built-in driver	Driver handles replica set
Cassandra	CQL	Client-side or L4	Token-aware routing preferred

Read Replica Load Balancing

The most common database LB pattern: distributing read queries across multiple replicas:

Write traffic → Primary/master database (single instance)
Read traffic → Load balanced across replicas

Layer 4 load balancing for read replicas:

Distributes connections to available replicas
Health checks via TCP connect or custom script
Removes unhealthy replicas from rotation
Session persistence often required for transactions

Connection Pooling

Database connections are expensive (memory, authentication, TLS). Architectures typically use:

Server-side poolers: PgBouncer (PostgreSQL), ProxySQL (MySQL)
Layer 4 LB to pooler: Distribute application connections to pooler instances
Pooler to database: Multiplexed, persistent connections

The Layer 4 LB distributes application connections; the pooler manages database connections.

Converting Mermaid diagram...

Protocol-Aware Database Proxies

Layer 4 Use Case: High-Frequency Trading and Financial Systems

The Latency Arms Race

In high-frequency trading (HFT):

Speed = profit: Being 1ms faster than competitors means executing better trades
Every component matters: Network cards, switches, cables, and load balancers are all optimized
Microseconds are measured: Systems track latency in microseconds, not milliseconds
Hardware acceleration is common: FPGAs, custom ASICs, kernel bypass

Financial Trading Latency Budgets
System Tier	Total Latency Budget	LB Allocation	LB Technology
Ultra-low latency HFT	< 10 µs	< 1 µs	FPGA/ASIC, no LB
Low-latency trading	< 100 µs	< 5 µs	DPDK/XDP, L4 only
Market making	< 1 ms	< 50 µs	L4 software
Execution services	< 10 ms	< 500 µs	L4 or L7
Retail trading	< 100 ms	< 5 ms	L7 acceptable

Financial Protocol Requirements

Financial systems use specialized protocols:

FIX (Financial Information eXchange): Text-based protocol over TCP
FAST (FIX Adapted for Streaming): Binary, compressed market data
ITCH/OUCH: NASDAQ proprietary order entry protocols
Binary Exchange Protocols: Exchange-specific order and data protocols

These protocols require Layer 4 handling—they're not HTTP.

Architecture Patterns

Market data distribution:

Exchange feed → Feed handler
L4 LB or multicast → Multiple consumers
Consumers process independently

Order routing:

Trading engine → L4 LB
LB → Exchange gateway (primary or backup)
Session persistence: Same gateway for cancel/modify

Cross-datacenter:

Active-active in multiple locations
L4 LB with latency-based routing
Automatic failover < 100µs

trading-latency-components.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Ultra-Low Latency Trading System Component Breakdown
====================================================
 
Total round-trip budget: 50 microseconds
 
Component Breakdown:
--------------------
Network (fiber, switch):    15 µs  (30%)
NIC processing:              3 µs  ( 6%)
Kernel network stack:        5 µs  (10%)  ← eliminated with bypass
Load balancer:               5 µs  (10%)  ← L4 only, kernel bypass
Application logic:          20 µs  (40%)
Response path:               2 µs  ( 4%)
 
With Optimization:
------------------
FPGA NIC (no kernel):        1 µs
No load balancer (direct):   0 µs
Co-located exchange:         5 µs wire
------------------------------------
Achievable:                < 10 µs round-trip
 
Key: Every component that touches packets is
     measured and optimized. Layer 7 (adding 1-5ms)
     would consume 20-100x the entire budget.

When Load Balancers Are Eliminated

Layer 7 Use Case: Web Applications and APIs

Web applications and REST/GraphQL APIs are the primary domain for Layer 7 load balancing. The HTTP protocol's richness and the need for content-based routing make Layer 7 essential.

Why Layer 7 Is Essential for Web

Virtual hosting: Multiple domains on single IP
Path-based routing: /api and /web to different backends
TLS termination: Centralized certificate management
HTTP rewriting: Headers, URLs, redirects
Caching: Edge caching of static content
Compression: Response compression
Security: WAF, rate limiting, authentication

Typical Web Application Routing

•/ → Frontend server (React/Vue/Angular)
•/api/ → API backend cluster
•/static/ → CDN or static file server
•/admin/ → Admin panel (restricted network)
•/health → Health check response
•/ws/ → WebSocket server cluster

Layer 7 Benefits for Web

•Single entry point for all services
•Centralized TLS certificate management
•Request logging and metrics
•A/B testing and canary deployments
•Rate limiting per endpoint
•WAF protection at edge

API Gateway Pattern

Layer 7 load balancers often implement the API Gateway pattern:

Single entry point: All API traffic through one endpoint
Authentication: Validate tokens at the gateway
Rate limiting: Enforce quotas per client/endpoint
Request transformation: Add headers, rewrite paths
Response aggregation: Combine multiple backend calls
Caching: Cache responses at the edge

E-commerce Example

A typical e-commerce platform routing configuration:

ecommerce-routing.yaml
YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
# E-commerce Layer 7 Routing Configuration
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ecommerce-ingress
  annotations:
    nginx.ingress.kubernetes.io/rate-limit: "100"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  tls:
    - hosts: [shop.example.com, api.example.com]
      secretName: ecommerce-tls
  rules:
    # Main website
    - host: shop.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend
                port: {number: 80}
          - path: /checkout
            pathType: Prefix
            backend:
              service:
                name: checkout-service
                port: {number: 80}
    
    # API endpoints
    - host: api.example.com
      http:
        paths:
          - path: /v1/products
            pathType: Prefix
            backend:
              service:
                name: product-service
                port: {number: 8080}
          - path: /v1/orders
            pathType: Prefix
            backend:
              service:
                name: order-service
                port: {number: 8080}
          - path: /v1/users
            pathType: Prefix
            backend:
              service:
                name: user-service
                port: {number: 8080}

Web Performance Context

Layer 7 Use Case: Microservices and Service Mesh

Microservices architectures are fundamentally dependent on Layer 7 load balancing. The need to route requests to the appropriate service based on path, header, or content makes Layer 7 essential.

The Microservices Routing Challenge

In a microservices architecture:

Many services: Tens to thousands of independent services
Single entry point expected: Users expect one domain, not service-1.example.com, service-2.example.com
Dynamic discovery: Services scale up/down, change locations
Sophisticated routing: Version routing, canary deployments, A/B testing

Layer 4 cannot solve this problem—it has no concept of HTTP paths or headers.

North-South vs East-West Traffic

North-South (external entry):

Client → Ingress Layer 7 LB → Services
TLS termination, external routing
API gateway functionality

East-West (service-to-service):

Service A → Sidecar/Service Mesh → Service B
Internal Layer 7 routing
mTLS, observability, retry logic

Converting Mermaid diagram...

Service Mesh and Layer 7

Service meshes (Istio, Linkerd, Consul Connect) implement Layer 7 load balancing through sidecar proxies:

Capabilities:

Automatic mTLS: Encrypted service-to-service communication
Intelligent routing: Version-based, header-based, percentage-based splits
Resilience: Circuit breakers, retries, timeouts per route
Observability: Metrics, logs, and traces for every request
Policy enforcement: Rate limiting, authorization rules

Trade-off:

Each proxy adds ~1-5ms latency per hop
For a request traversing 5 services: 5-25ms added latency
Usually acceptable; for latency-critical paths, direct connections may be needed

Service Mesh Layer 7 Capabilities
Feature	Without Service Mesh	With Service Mesh
Service discovery	Manual/DNS	Automatic, dynamic
Load balancing	Client library or L4	L7 with intelligent routing
mTLS	Manual certificate management	Automatic, transparent
Observability	Instrument each service	Automatic per-request metrics
Traffic splitting	Application code	Configuration-driven
Circuit breaking	Library per service	Centralized policy

When to Adopt Service Mesh

Layer 7 Use Case: Security, Authentication, and WAF

Security is often the decisive factor for Layer 7 adoption. Many security functions are inherently Layer 7 operations—they require understanding the application protocol.

Web Application Firewall (WAF)

WAFs protect against application-layer attacks:

SQL Injection: Detect malicious SQL patterns in parameters
Cross-Site Scripting (XSS): Block script injection attempts
Path traversal: Prevent ../../../etc/passwd attacks
Request smuggling: Detect malformed HTTP requests
Protocol violations: Reject invalid HTTP

Layer 4 cannot provide this protection—it doesn't understand HTTP.

OWASP Top 10 and Layer 7 Protection

•A01:2021 Broken Access Control → Path-based authorization at LB
•A02:2021 Cryptographic Failures → TLS termination with modern ciphers
•A03:2021 Injection → WAF pattern matching, input validation
•A04:2021 Insecure Design → Rate limiting, circuit breaking
•A05:2021 Security Misconfiguration → Security headers injection
•A07:2021 Identification Failures → Centralized authentication at gateway
•A09:2021 Logging Failures → Comprehensive request logging at L7

Centralized Authentication

Layer 7 load balancers can offload authentication from backends:

Token validation:

Request arrives with Authorization header
LB validates JWT signature and claims
If valid: Add X-User-ID header, forward to backend
If invalid: Return 401 immediately

Benefits:

Backends don't need authentication logic
Consistent enforcement across all services
Centralized token management (key rotation)
Reduced backend load (invalid requests rejected at edge)

Rate Limiting and DDoS Protection

Layer 7 enables sophisticated rate limiting:

Per client: Limit by IP, user ID, API key
Per endpoint: Different limits for /search vs /checkout
Adaptive: Dynamic limits based on system load
Distributed: Synchronized limits across LB instances

For DDoS, Layer 7 can:

Challenge suspected bots (CAPTCHA, JavaScript challenges)
Block by request pattern (not just IP)
Absorb application-layer attacks (HTTP floods)

security-configuration.yaml
YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# Layer 7 Security Configuration (Envoy-style)
http_filters:
  # JWT Authentication
  - name: envoy.filters.http.jwt_authn
    typed_config:
      providers:
        auth0:
          issuer: "https://example.auth0.com/"
          audiences: ["api.example.com"]
          remote_jwks:
            http_uri:
              uri: "https://example.auth0.com/.well-known/jwks.json"
      rules:
        - match: {prefix: "/api/"}
          requires:
            provider_name: auth0
        - match: {prefix: "/public/"}  # No auth required
  
  # Rate Limiting
  - name: envoy.filters.http.ratelimit
    typed_config:
      domain: api_rate_limit
      rate_limit_service:
        grpc_service:
          envoy_grpc:
            cluster_name: rate_limit_cluster
      descriptors:
        - entries:
            - key: user_id
              value: "%REQ(X-User-ID)%"
        - entries:
            - key: path
              value: "%REQ(:path)%"
  
  # WAF (ModSecurity rules)
  - name: envoy.filters.http.wasm
    typed_config:
      vm_config:
        code:
          local: {filename: "/etc/envoy/wasm/coraza-waf.wasm"}

Defense in Depth

Hybrid Architectures: Combining Layer 4 and Layer 7

Production systems rarely use Layer 4 or Layer 7 exclusively. Hybrid architectures leverage both layers strategically, optimizing for their respective strengths.

Common Hybrid Patterns

Pattern 1: Layer 4 in Front of Layer 7

The most common hybrid: Layer 4 handles connection distribution; Layer 7 handles application routing.

Internet → L4 LB → L7 LBs → Services

Benefits:

L4 provides health checking and failover for L7 instances
L4 can do basic DDoS mitigation (SYN flood protection)
L7 can be scaled horizontally behind L4
L4 is stateless (easy HA); L7 maintains application context

Example: AWS architecture with NLB in front of ALB (common for WebSocket + HTTP).

Converting Mermaid diagram...

Pattern 2: Split by Protocol

Different protocols get different treatment:

HTTP/HTTPS → L7 LB → Web/API services
TCP/UDP (gaming, DB) → L4 LB → Specialized services

Example: Gaming company with HTTP APIs through L7, game traffic through L4.

Pattern 3: Split by Sensitivity

Latency-sensitive traffic bypasses Layer 7:

Critical path → L4 or direct
General traffic → L7 with full features

Example: Trading platform with order execution on L4, everything else on L7.

Pattern 4: TLS Passthrough + HTTP Termination

External TLS → L7 terminates → Backend
Internal TLS (mTLS) → L4 passthrough → Backend terminates

Example: Ingress terminates external TLS; internal mTLS passes through.

Hybrid Architecture Decision Matrix
Traffic Type	Layer	Rationale
Public HTTP/HTTPS	L7	Routing, TLS, WAF, caching
Internal HTTP	L7 (service mesh) or L4	Observability vs simplicity
Database connections	L4	Binary protocol, performance
WebSocket	L7 or L4	L7 for routing; L4 for simplicity
Gaming UDP	L4	Custom protocol, latency
gRPC	L7 (gRPC-aware)	Stream routing, health checks

Complexity vs Capability

Summary: Use Cases for Each Layer

Key Takeaways

•Gaming requires Layer 4: Custom UDP protocols, microsecond-sensitive latency, and high packet rates demand Layer 4
•Databases require Layer 4: Binary protocols that Layer 7 cannot parse; often combined with protocol-aware proxies
•Trading systems minimize layers: Extreme latency sensitivity may eliminate load balancers entirely
•Web applications thrive on Layer 7: Path routing, TLS termination, observability, and security features are essential
•Microservices require Layer 7: Service mesh and intelligent routing are foundational to the architecture
•Security features are Layer 7: WAF, authentication, and sophisticated rate limiting need protocol awareness
•Hybrid architectures are common: Layer 4 in front of Layer 7, split by protocol, or split by sensitivity

What's next:

Page Complete

4 / 5