Layer 7 Load Balancing: HTTP-Aware Routing Guide

TL;DR

Layer 7 load balancers operate at the application layer, inspecting HTTP/HTTPS content (URLs, headers, cookies, request bodies) to make intelligent routing decisions. Unlike Layer 4 load balancers that route based solely on IP and port, L7 LBs can route /api/* requests to API servers, /images/* to CDN origins, or direct mobile traffic to optimized backends. This flexibility comes at a cost: higher latency (5-20ms overhead) and CPU usage due to payload inspection and SSL termination. Cheat sheet: Use L7 for microservices routing, A/B testing, canary deployments, and API gateways where content-aware routing justifies the performance overhead.

Background

When Netflix migrated from monolithic architecture to microservices in 2012, they faced a critical problem: how do you route /browse requests to the catalog service, /play to the streaming service, and /account to the billing service using a single entry point? Layer 4 load balancers couldn’t help—they only see IP addresses and TCP ports, treating all traffic to port 443 identically. This drove the need for application-aware load balancing.

Layer 7 load balancing emerged from the need to make routing decisions based on application semantics, not just network packets. The term “Layer 7” refers to the OSI model’s application layer, where protocols like HTTP, HTTPS, WebSocket, and gRPC operate. Unlike Layer 4 load balancers that forward TCP/UDP packets blindly, L7 load balancers terminate connections, parse application protocols, inspect message content, and make routing decisions based on URLs, headers, cookies, or even request body content.

The technology gained prominence with the rise of microservices (2010s) and API-driven architectures. Companies like Uber needed to route thousands of different API endpoints to hundreds of backend services through a single ingress point. Traditional hardware load balancers like F5 BIG-IP added L7 capabilities, while software solutions like HAProxy, NGINX, and cloud-native options like AWS ALB became the standard. Today, L7 load balancing is fundamental to modern web architecture, enabling everything from blue-green deployments to sophisticated traffic shaping.

Architecture

A Layer 7 load balancer sits between clients and backend servers, acting as a full HTTP proxy. Unlike L4 load balancers that simply forward packets, L7 LBs establish two separate connections: one from the client to the load balancer, and another from the load balancer to the selected backend server. This “connection termination” is fundamental to how L7 works.

The core components include: (1) Connection handler that accepts incoming TCP connections and manages the TLS handshake for HTTPS traffic, (2) Protocol parser that reads and interprets HTTP requests, extracting headers, URLs, cookies, and body content, (3) Routing engine that evaluates routing rules against the parsed request to select a backend pool, (4) Health checker that monitors backend server health via HTTP endpoints (e.g., GET /health), (5) Connection pool manager that maintains persistent connections to backend servers to reduce latency, and (6) Response processor that can modify responses before returning them to clients.

The request flow works like this: A client sends an HTTPS request to api.company.com/users/123. The L7 load balancer terminates the TLS connection, decrypts the request, and parses the HTTP headers. The routing engine evaluates rules like “if path starts with /users, route to user-service pool” and selects a healthy backend server using an algorithm (round-robin, least connections, etc.). The LB establishes or reuses a connection to the chosen backend, forwards the request (often as plain HTTP), receives the response, optionally modifies it (adding headers, compressing), and returns it to the client over the original TLS connection.

This architecture enables powerful capabilities but introduces a critical trade-off: the load balancer becomes a stateful component that must maintain connection state, parse every request, and perform cryptographic operations. This is why L7 load balancers consume significantly more CPU and memory than L4 alternatives.

Layer 7 Load Balancer Architecture and Request Flow

graph LR
    Client["Client<br/><i>Browser/Mobile</i>"]
    
    subgraph L7 Load Balancer
        ConnHandler["Connection Handler<br/><i>TLS Termination</i>"]
        Parser["HTTP Parser<br/><i>Extract Headers/Path</i>"]
        RoutingEngine["Routing Engine<br/><i>Evaluate Rules</i>"]
        HealthCheck["Health Checker<br/><i>Monitor Backends</i>"]
        ConnPool["Connection Pool<br/><i>Persistent Connections</i>"]
    end
    
    subgraph Backend Pools
        API1["API Server 1"]
        API2["API Server 2"]
        Web1["Web Server 1"]
        Web2["Web Server 2"]
    end
    
    Client --"1. HTTPS Request<br/>GET /api/users"--> ConnHandler
    ConnHandler --"2. Decrypt TLS<br/>Parse HTTP"--> Parser
    Parser --"3. Extract path=/api/users<br/>headers, cookies"--> RoutingEngine
    RoutingEngine --"4. Match rule:<br/>path=/api/* → API pool"--> ConnPool
    ConnPool --"5. Select healthy server<br/>Reuse connection"--> API1
    API1 --"6. HTTP Response"--> ConnPool
    ConnPool --"7. Return to client<br/>over TLS"--> Client
    HealthCheck -."Periodic GET /health".-> API1
    HealthCheck -."Periodic GET /health".-> API2
    HealthCheck -."Periodic GET /health".-> Web1

Layer 7 load balancer establishes two separate connections (client-to-LB and LB-to-backend), terminates TLS, parses HTTP content, evaluates routing rules, and maintains connection pools to backends. This connection termination enables content inspection but adds latency compared to Layer 4 packet forwarding.

Layer 7 vs Layer 4 Load Balancing Comparison

graph TB
    subgraph Layer 4 Load Balancer
        L4Client["Client"]
        L4LB["L4 Load Balancer<br/><i>Packet Forwarding</i>"]
        L4Back1["Backend 1<br/><i>10.0.1.10:443</i>"]
        L4Back2["Backend 2<br/><i>10.0.1.11:443</i>"]
        
        L4Client --"TCP SYN to 443"--> L4LB
        L4LB --"Forward packets<br/>based on IP:Port"--> L4Back1
        L4LB --"Round-robin<br/>or least connections"--> L4Back2
        
        L4Note["✓ Low latency: 1-2ms<br/>✓ High throughput<br/>✓ Protocol agnostic<br/>✗ No content inspection<br/>✗ Cannot route by URL/header"]
    end
    
    subgraph Layer 7 Load Balancer
        L7Client["Client"]
        L7LB["L7 Load Balancer<br/><i>HTTP Proxy</i>"]
        L7API["API Servers<br/><i>/api/*</i>"]
        L7Web["Web Servers<br/><i>/static/*</i>"]
        L7Admin["Admin Backend<br/><i>/admin/*</i>"]
        
        L7Client --"HTTPS Request<br/>GET /api/users"--> L7LB
        L7LB --"Terminate TLS<br/>Parse HTTP<br/>Route by path"--> L7API
        L7LB --"Different path"--> L7Web
        L7LB --"Different path"--> L7Admin
        
        L7Note["✓ Content-based routing<br/>✓ SSL termination<br/>✓ Request/response modification<br/>✗ Higher latency: 5-20ms<br/>✗ 3-5x more CPU usage"]
    end

Layer 4 load balancers forward TCP/UDP packets based on IP and port, offering low latency (1-2ms) but no content awareness. Layer 7 load balancers terminate connections, parse HTTP, and route based on URLs, headers, and cookies, enabling sophisticated routing at the cost of higher latency (5-20ms) and CPU usage.

Internals

Under the hood, Layer 7 load balancers implement sophisticated request processing pipelines. When a request arrives, the LB uses an event-driven I/O model (epoll on Linux, kqueue on BSD) to handle thousands of concurrent connections efficiently. HAProxy and NGINX both use single-threaded event loops with non-blocking I/O, while cloud load balancers like AWS ALB distribute across multiple processing nodes.

The HTTP parsing phase is performance-critical. Modern L7 LBs use state machines to parse HTTP/1.1 requests incrementally without buffering entire messages. For HTTP/2, they maintain per-stream state and handle multiplexing, where multiple requests share a single TCP connection. The parser extracts routing-relevant data: the request method, path, query parameters, headers (Host, User-Agent, Cookie, custom headers), and optionally the request body for POST/PUT requests.

Routing decisions use a rule evaluation engine. In NGINX, this is the location directive matching system that evaluates rules in a specific order (exact match, longest prefix match, regex). In HAProxy, ACLs (Access Control Lists) define conditions like acl is_api path_beg /api combined with backend selection rules use_backend api_servers if is_api. Cloud load balancers like AWS ALB use listener rules with priority ordering, evaluating conditions like path patterns, HTTP headers, source IPs, and query strings.

SSL/TLS termination is computationally expensive. The load balancer performs the TLS handshake, which involves asymmetric cryptography (RSA or ECDSA for key exchange) and symmetric encryption (AES-GCM for data). Modern LBs optimize this with session resumption (TLS session tickets), hardware acceleration (AES-NI CPU instructions), and connection pooling to backends. When forwarding to backends, many deployments use plain HTTP to avoid double encryption overhead, relying on network isolation for security.

Connection pooling is crucial for performance. Instead of creating a new TCP connection for every request, L7 LBs maintain pools of persistent connections to each backend server. When a request needs routing to backend-1, the LB reuses an existing connection from the pool, eliminating TCP handshake and slow-start overhead. HTTP/1.1 keep-alive and HTTP/2 multiplexing make this even more efficient.

Health checking at Layer 7 goes beyond TCP port checks. The LB sends periodic HTTP requests to health endpoints (e.g., GET /health every 5 seconds) and expects specific responses (HTTP 200 with optional body content checks). This catches application-level failures that TCP checks miss, like a server that accepts connections but returns 500 errors. Failed health checks trigger automatic removal from the backend pool until recovery.

SSL/TLS Termination and Connection Pooling

sequenceDiagram
    participant Client
    participant LB as L7 Load Balancer
    participant Backend as Backend Server
    
    Note over Client,LB: Initial Request (HTTPS)
    Client->>LB: 1. TLS Handshake (ClientHello)
    LB->>Client: 2. TLS Handshake (ServerHello, Certificate)
    Note over LB: Asymmetric crypto: RSA/ECDSA<br/>Cost: 1-3ms
    Client->>LB: 3. Encrypted HTTP Request<br/>GET /api/users
    Note over LB: Decrypt with session key<br/>AES-GCM (hardware accelerated)
    LB->>LB: 4. Parse HTTP headers<br/>Extract path, headers, cookies
    Note over LB: Routing decision:<br/>path=/api/* → API pool
    
    alt Connection Pool Has Available Connection
        LB->>Backend: 5. Reuse pooled connection<br/>Plain HTTP GET /api/users
        Note over LB,Backend: No TCP handshake overhead<br/>Saves 1-2ms
    else No Available Connection
        LB->>Backend: 5. New TCP connection + HTTP request
        Note over LB,Backend: TCP handshake + slow start<br/>Adds 1-2ms latency
    end
    
    Backend->>LB: 6. HTTP Response (200 OK)
    LB->>LB: 7. Optional: Add headers,<br/>compress response
    LB->>Client: 8. Encrypted response over TLS
    Note over Client,LB: Subsequent Request (Session Resumption)
    Client->>LB: 9. TLS Session Ticket<br/>(no full handshake)
    Note over LB: Session resumption<br/>Cost: <1ms
    LB->>Backend: 10. Reuse pooled connection
    Backend->>LB: 11. Response
    LB->>Client: 12. Encrypted response

SSL/TLS termination at the load balancer decrypts HTTPS traffic (1-3ms for initial handshake, <1ms with session resumption), enabling content inspection. Connection pooling to backends reuses TCP connections, eliminating handshake overhead and reducing latency by 50-70% for subsequent requests.

Advanced Routing Capabilities

Layer 7’s killer feature is content-based routing, which enables sophisticated traffic management impossible at Layer 4. Path-based routing is the most common pattern: directing /api/* requests to API servers, /static/* to CDN origins, and /admin/* to a separate administrative backend. Netflix uses this extensively, routing /browse to catalog services, /play to streaming infrastructure, and /account to billing systems—all through a single Zuul gateway.

Host-based routing (virtual hosting) allows multiple domains to share a single load balancer IP. A request to api.company.com routes to API servers, while www.company.com routes to web servers, and admin.company.com routes to admin infrastructure. This is fundamental to multi-tenant SaaS platforms where each customer gets a subdomain (customer1.saas.com, customer2.saas.com) routing to isolated backend pools.

Header-based routing enables sophisticated use cases. User-Agent routing sends mobile traffic (User-Agent: Mobile) to mobile-optimized backends with smaller payloads and different caching strategies. Custom header routing supports canary deployments: requests with X-Canary: true route to the new version while production traffic hits stable servers. Uber uses header-based routing to direct internal requests (with specific authentication headers) to different backend pools than external customer requests.

Cookie-based routing enables session affinity (sticky sessions) and A/B testing. For session affinity, the LB sets a cookie like SERVER_ID=backend-3 on the first request, then routes subsequent requests from that client to the same backend server. This is critical for applications with in-memory session state. For A/B testing, the LB can route users with experiment=variant-b cookies to experimental backends while control group users hit the standard backend.

Microservices routing is where L7 truly shines. A single API gateway load balancer can route hundreds of endpoints to dozens of services: POST /orders → order-service, GET /users/{id} → user-service, GET /products → catalog-service. The routing rules can be arbitrarily complex, combining path, method, headers, and query parameters. Stripe’s API gateway routes thousands of different API endpoints through a single entry point, handling authentication, rate limiting, and service routing in one layer.

Canary deployments leverage weighted routing. You can send 95% of /api/users traffic to stable servers and 5% to the new version, gradually increasing the percentage while monitoring error rates. If the canary shows elevated errors, you route 100% back to stable servers instantly. This is safer than blue-green deployments because it limits blast radius.

Query parameter routing enables feature flags and versioning. Requests with ?version=v2 route to new API servers, while default traffic hits v1. Geographic routing based on headers like CloudFront-Viewer-Country can send EU traffic to EU-compliant backends and US traffic to US servers, helping with GDPR compliance.

Content-Based Routing Patterns in Layer 7

graph TB
    Client["Client Requests"]
    LB["L7 Load Balancer<br/><i>Routing Engine</i>"]
    
    subgraph Path-Based Routing
        API["API Servers<br/><i>/api/*</i>"]
        Static["CDN Origin<br/><i>/static/*</i>"]
        Admin["Admin Backend<br/><i>/admin/*</i>"]
    end
    
    subgraph Host-Based Routing
        APIDomain["API Servers<br/><i>api.company.com</i>"]
        WebDomain["Web Servers<br/><i>www.company.com</i>"]
    end
    
    subgraph Header-Based Routing
        Mobile["Mobile Backend<br/><i>User-Agent: Mobile</i>"]
        Canary["Canary Servers<br/><i>X-Canary: true</i>"]
    end
    
    subgraph Cookie-Based Routing
        SessionA["Backend A<br/><i>SESSION_ID=server-a</i>"]
        ExperimentB["Experiment B<br/><i>experiment=variant-b</i>"]
    end
    
    Client --"GET /api/users"--> LB
    Client --"GET /static/logo.png"--> LB
    Client --"Host: api.company.com"--> LB
    Client --"User-Agent: Mobile"--> LB
    Client --"Cookie: experiment=variant-b"--> LB
    
    LB --"Path match"--> API
    LB --"Path match"--> Static
    LB --"Host header"--> APIDomain
    LB --"Header inspection"--> Mobile
    LB --"Cookie value"--> ExperimentB

Layer 7 enables sophisticated content-based routing by inspecting HTTP paths, host headers, custom headers, and cookies. This allows a single load balancer to route thousands of different request types to appropriate backend pools, enabling microservices architectures, A/B testing, and multi-tenant isolation.

Performance Characteristics

Layer 7 load balancing introduces measurable performance overhead compared to Layer 4. The additional latency comes from connection termination, HTTP parsing, SSL/TLS operations, and routing logic evaluation. In production systems, expect 5-20ms of added latency per request, depending on configuration and load.

SSL/TLS termination is the biggest contributor. A TLS handshake with RSA-2048 takes 1-3ms on modern hardware, while ECDSA P-256 reduces this to 0.5-1ms. Session resumption via TLS session tickets eliminates handshake overhead for subsequent requests from the same client, reducing latency to <1ms. Hardware acceleration (AES-NI) makes symmetric encryption nearly free, but the asymmetric operations during handshake remain expensive.

HTTP parsing adds 0.1-0.5ms per request for typical payloads. HTTP/2 parsing is slightly more expensive due to HPACK header compression and stream multiplexing, but the benefits (multiplexing, header compression) usually outweigh the cost. Request body inspection for routing decisions can add significant latency if you’re parsing JSON or XML—avoid this unless absolutely necessary.

Throughput depends heavily on request size and complexity. A well-tuned NGINX or HAProxy instance on modern hardware (16 cores, 64GB RAM) can handle 50,000-100,000 requests/second for small requests (<1KB) with simple routing rules. Complex routing logic (regex matching, header manipulation) reduces this to 20,000-40,000 req/s. Large requests (>100KB) shift the bottleneck to network I/O rather than CPU.

Cloud load balancers scale differently. AWS ALB automatically scales to handle traffic spikes but has higher baseline latency (10-20ms) compared to self-hosted solutions (5-10ms). The trade-off is operational simplicity: ALB handles scaling, health checks, and SSL certificate management automatically.

Connection pooling dramatically improves backend performance. Without pooling, each request incurs TCP handshake overhead (1-2ms) and slow-start penalties. With pooling, subsequent requests reuse existing connections, reducing backend latency by 50-70%. HTTP/2 to backends enables multiplexing, where a single connection handles hundreds of concurrent requests.

Memory usage scales with concurrent connections. Each active connection consumes 10-50KB depending on buffer sizes and TLS state. A load balancer handling 100,000 concurrent connections needs 1-5GB of RAM just for connection state, plus additional memory for routing tables and health check state.

Trade-offs

Layer 7 load balancing excels at intelligent routing, protocol-aware features, and operational flexibility, but these benefits come with clear costs. The primary advantage is routing sophistication: you can route based on any aspect of the HTTP request, enabling microservices architectures, A/B testing, canary deployments, and multi-tenant isolation. This is impossible with Layer 4, which only sees IP addresses and ports.

SSL/TLS termination centralizes certificate management and reduces backend complexity. Instead of managing certificates on every backend server, you configure them once on the load balancer. Backends receive plain HTTP, simplifying application code and reducing CPU usage on application servers. The load balancer can also enforce modern TLS versions (TLS 1.3) and cipher suites while maintaining compatibility with older clients.

Request/response modification enables powerful transformations. L7 LBs can add security headers (X-Frame-Options, Strict-Transport-Security), remove sensitive headers before forwarding to backends, compress responses with gzip/brotli, or rewrite URLs. AWS ALB can inject custom headers like X-Forwarded-For to preserve client IP addresses, critical for logging and security.

The cost is performance and complexity. L7 load balancers consume 3-5x more CPU than L4 alternatives for the same traffic volume due to HTTP parsing and SSL operations. Latency increases by 5-20ms per request, which matters for latency-sensitive applications. The load balancer becomes a stateful component that must maintain connection state, making it harder to scale horizontally and creating a potential single point of failure.

Debugging is more complex because the load balancer modifies requests and responses. A bug in routing rules can send traffic to the wrong backend, and troubleshooting requires understanding both the LB configuration and application behavior. Layer 4 load balancers are transparent, making debugging simpler.

Security is a double-edged sword. SSL termination means the load balancer sees all traffic in plaintext, making it a high-value target. If compromised, an attacker can intercept all traffic. Layer 4 load balancers never see decrypted traffic, reducing attack surface. However, L7 LBs can implement WAF (Web Application Firewall) rules, rate limiting, and authentication, providing defense-in-depth that L4 cannot.

Cost matters at scale. Cloud L7 load balancers (AWS ALB, GCP HTTPS LB) charge per LCU (Load Balancer Capacity Unit) based on connections, requests, and bandwidth. For high-traffic applications, this can cost thousands per month more than L4 alternatives. Self-hosted solutions require more powerful hardware due to CPU overhead.

When to Use (and When Not To)

Choose Layer 7 load balancing when you need content-aware routing or protocol-specific features that justify the performance overhead. The decision hinges on whether your routing logic requires inspecting HTTP content or whether simple IP/port-based routing suffices.

Use L7 for microservices architectures where a single entry point must route to multiple backend services based on URL paths. If you’re building an API gateway that routes /users to user-service, /orders to order-service, and /payments to payment-service, L7 is essential. Layer 4 cannot distinguish these paths.

Choose L7 for A/B testing and canary deployments where you need to route a percentage of traffic to experimental backends based on cookies, headers, or user attributes. If you’re rolling out a new feature to 5% of users, L7’s weighted routing and header-based routing make this trivial.

Use L7 when SSL/TLS termination simplifies your architecture. If managing certificates on dozens of backend servers is operationally painful, centralizing SSL on the load balancer reduces complexity. This is especially valuable in Kubernetes environments where pods are ephemeral.

Choose L7 for multi-tenant SaaS applications where different customers route to isolated backend pools based on subdomain or custom headers. Host-based routing enables customer1.saas.com and customer2.saas.com to share a single load balancer IP while routing to separate infrastructure.

Avoid L7 when latency is critical and routing logic is simple. If you’re building a high-frequency trading system or real-time gaming backend where every millisecond matters, Layer 4’s lower latency (1-2ms vs 5-20ms) is worth the trade-off. Use L4 for simple round-robin or least-connections routing.

Avoid L7 for non-HTTP protocols. If you’re load balancing TCP databases (PostgreSQL, MySQL), message queues (Kafka, RabbitMQ), or custom binary protocols, Layer 4 is the only option. L7 load balancers are HTTP-specific (though some support gRPC and WebSocket).

Consider hybrid approaches: use L4 for the initial entry point to distribute traffic across multiple L7 load balancers, then use L7 for intelligent routing within each cluster. This is how Netflix and Uber scale: L4 load balancers (AWS NLB) distribute traffic geographically, then L7 gateways (Zuul, Envoy) handle microservices routing.

If you’re unsure, start with L7. The operational benefits (easier debugging, centralized SSL, flexible routing) usually outweigh the performance cost for most web applications. You can always optimize to L4 later if profiling shows the load balancer is a bottleneck.

Microservices API Gateway with Layer 7 Routing

graph LR
    Client["Client<br/><i>Mobile/Web</i>"]
    
    subgraph API Gateway - Layer 7 Load Balancer
        Gateway["L7 Load Balancer<br/><i>SSL Termination + Routing</i>"]
    end
    
    subgraph Microservices Backend
        UserSvc["User Service<br/><i>GET /users/*<br/>POST /users</i>"]
        OrderSvc["Order Service<br/><i>GET /orders/*<br/>POST /orders</i>"]
        PaymentSvc["Payment Service<br/><i>POST /payments<br/>GET /payments/*</i>"]
        CatalogSvc["Catalog Service<br/><i>GET /products<br/>GET /categories</i>"]
        AuthSvc["Auth Service<br/><i>POST /auth/login<br/>POST /auth/refresh</i>"]
    end
    
    Client --"1. HTTPS Request<br/>api.company.com"--> Gateway
    
    Gateway --"Path: /users/*<br/>Method: GET/POST"--> UserSvc
    Gateway --"Path: /orders/*<br/>Method: GET/POST"--> OrderSvc
    Gateway --"Path: /payments/*<br/>Method: POST/GET"--> PaymentSvc
    Gateway --"Path: /products<br/>Path: /categories"--> CatalogSvc
    Gateway --"Path: /auth/*<br/>Method: POST"--> AuthSvc
    
    Note1["Single entry point<br/>routes 100+ endpoints<br/>to 20+ services"]
    Note2["SSL termination<br/>Authentication<br/>Rate limiting<br/>Request logging"]

Layer 7 load balancers are essential for microservices architectures, routing hundreds of API endpoints to dozens of backend services through a single entry point. The gateway handles SSL termination, authentication, and intelligent routing based on HTTP paths and methods, impossible with Layer 4 load balancing.

Real-World Examples

company: Netflix system: Zuul API Gateway how_used: Netflix uses Zuul, a Layer 7 load balancer and API gateway, to route millions of requests per second across hundreds of microservices. Zuul inspects HTTP paths to route /browse requests to the catalog service, /play to streaming infrastructure, and /account to billing systems. It also performs SSL termination, authentication, rate limiting, and dynamic routing for canary deployments. interesting_detail: Zuul uses custom routing filters written in Groovy that can be deployed dynamically without restarting the gateway. During a major incident, Netflix engineers can push new routing rules in seconds to redirect traffic away from failing services, demonstrating L7’s operational flexibility. Zuul 2 (the current version) handles over 1 million requests per second per instance using asynchronous I/O.

company: Uber system: API Gateway (Envoy-based) how_used: Uber migrated from a monolithic architecture to thousands of microservices, requiring sophisticated L7 routing. Their API gateway uses Envoy Proxy to route over 2,000 different API endpoints to hundreds of backend services based on path, headers, and authentication context. The gateway performs SSL termination, request authentication via JWT tokens, rate limiting per customer, and weighted routing for gradual rollouts. interesting_detail: Uber’s gateway uses header-based routing to distinguish between rider and driver requests, routing them to different backend pools with different SLAs. Rider requests (latency-sensitive) get priority routing and lower timeouts, while driver requests (less latency-sensitive) tolerate higher latency. This header-based differentiation is impossible with Layer 4 load balancing.

company: AWS system: Application Load Balancer (ALB) how_used: AWS ALB is a managed Layer 7 load balancer used by thousands of companies for microservices routing, SSL termination, and content-based routing. ALB supports path-based routing (route /api/* to API targets), host-based routing (route by domain), HTTP header routing, and query parameter routing. It integrates with AWS Certificate Manager for automatic SSL certificate renewal and AWS WAF for application-layer security. interesting_detail: ALB automatically scales to handle traffic spikes without manual intervention, using a distributed architecture that provisions additional load balancer nodes as traffic increases. During AWS re:Invent 2023, ALB handled a 10x traffic spike for a customer’s product launch by automatically scaling from 10 to 100+ nodes in under 5 minutes, demonstrating cloud L7 LB elasticity that’s impossible with self-hosted solutions.

---

Interview Essentials

Mid-Level

Explain how Layer 7 load balancing differs from Layer 4. Focus on connection termination, HTTP parsing, and content-based routing vs. simple IP/port forwarding.

Describe path-based routing with a concrete example (e.g., routing /api/* to API servers and /static/* to CDN origins).

Explain SSL/TLS termination: why load balancers decrypt HTTPS traffic, the performance cost, and why backends often receive plain HTTP.

Walk through the request flow: client → LB (TLS handshake, HTTP parsing) → routing decision → backend selection → response processing → client.

Discuss when to use L7 vs L4: microservices routing, A/B testing, and SSL termination favor L7; low latency and non-HTTP protocols favor L4.

Senior

Design a microservices routing solution using L7 load balancing. Explain how you’d route 50+ different API endpoints to 20+ backend services, handle authentication, and implement rate limiting.

Analyze the performance trade-offs: quantify the latency overhead (5-20ms), CPU cost (3-5x higher than L4), and memory usage (10-50KB per connection). When is this acceptable?

Explain how you’d implement canary deployments using weighted routing. How do you monitor error rates and automatically roll back if the canary fails?

Discuss connection pooling and HTTP/2 multiplexing. How do these optimizations reduce backend latency, and what are the configuration trade-offs?

Design a hybrid L4/L7 architecture for global scale. Where would you use L4 (geographic distribution) vs L7 (microservices routing), and why?

Explain how L7 load balancers handle health checks differently than L4. Why are HTTP health checks more reliable than TCP checks?

Staff+

Architect a multi-region API gateway with L7 load balancing for a company processing 1M requests/second. Address SSL termination, routing complexity, observability, and failure modes.

Evaluate AWS ALB vs self-hosted NGINX/HAProxy for a high-scale system. Consider cost (ALB charges per LCU), latency (ALB has higher baseline latency), operational complexity, and vendor lock-in.

Design a zero-downtime migration from monolith to microservices using L7 routing. How do you gradually shift traffic from the monolith to new services while maintaining backward compatibility?

Analyze the security implications of SSL termination. The load balancer sees all traffic in plaintext—how do you secure the LB itself, the LB-to-backend network, and handle compliance requirements (PCI-DSS, HIPAA)?

Optimize L7 load balancer performance for a latency-sensitive application. Discuss TLS session resumption, HTTP/2 to backends, connection pooling tuning, and when to consider hardware acceleration.

Design a rate limiting and DDoS protection strategy at the L7 layer. How do you distinguish legitimate traffic spikes from attacks, and what are the trade-offs of rate limiting at the LB vs application layer?

Common Interview Questions

What’s the difference between Layer 4 and Layer 7 load balancing? (Answer: L4 routes based on IP/port, L7 inspects HTTP content for routing decisions)

Why does Layer 7 load balancing have higher latency than Layer 4? (Answer: Connection termination, HTTP parsing, SSL/TLS operations add 5-20ms overhead)

How does SSL termination work, and why is it useful? (Answer: LB decrypts HTTPS, inspects content, forwards HTTP to backends; centralizes certificate management)

Can you give an example of content-based routing? (Answer: Path-based routing /api/* to API servers, host-based routing by domain, header-based routing for A/B testing)

When would you choose Layer 7 over Layer 4? (Answer: Microservices routing, A/B testing, SSL termination, API gateways; avoid for low-latency or non-HTTP protocols)

Red Flags to Avoid

Claiming L7 is always better than L4 without discussing performance trade-offs (latency, CPU cost)

Not understanding connection termination—thinking L7 LBs forward packets like L4

Inability to explain a concrete content-based routing example (path-based, host-based, header-based)

Not knowing that SSL termination means the LB sees plaintext traffic and the security implications

Confusing reverse proxy with load balancing (they overlap at L7 but serve different primary purposes)

Suggesting L7 for non-HTTP protocols (databases, message queues) where only L4 works

---

Key Takeaways

Layer 7 load balancers inspect HTTP/HTTPS content (URLs, headers, cookies) to make intelligent routing decisions, unlike Layer 4 which only sees IP addresses and ports. This enables microservices routing, A/B testing, and canary deployments.

SSL/TLS termination centralizes certificate management and reduces backend complexity, but means the load balancer sees all traffic in plaintext, creating security considerations. Backends typically receive plain HTTP over a trusted network.

The performance cost is real: L7 adds 5-20ms latency and consumes 3-5x more CPU than L4 due to connection termination, HTTP parsing, and cryptographic operations. This trade-off is acceptable for most web applications but critical for latency-sensitive systems.

Content-based routing is L7’s killer feature: path-based routing (/api/* → API servers), host-based routing (by domain), header-based routing (User-Agent, custom headers), and cookie-based routing enable sophisticated traffic management impossible at Layer 4.

Choose L7 for microservices architectures, API gateways, and scenarios requiring SSL termination or content-aware routing. Use L4 for simple routing, low-latency requirements, non-HTTP protocols, or when the performance overhead isn’t justified.

---