Side by side
| Dimension | Layer 4 | Layer 7 load balancing |
|---|---|---|
| Routing inputs | IP addresses, ports, and transport protocol | Application fields such as host, path, and headers |
| Balancing unit | TCP connection or UDP flow | Application request or stream, depending on protocol |
| Protocol support | TCP and, where supported, UDP | Explicitly supported application protocols |
| TLS handling | Can pass encrypted traffic through to backends | Must decrypt HTTPS to inspect HTTP fields |
| Routing features | Backend selection without HTTP semantics | Path routing, header rules, and request-based canaries |
| Processing cost | Avoids application parsing; implementation matters | Adds application parsing and policy processing |
| Observability | Connections, bytes, transport failures | Also request latency, status codes, and routes |
| Failure handling | New flows can avoid failed backends; existing flows may break | Can handle failures per request; retries need safeguards |
The differences that matter
The balancing unit changes load distribution. An L4 balancer generally keeps a TCP connection on one backend, so thousands of requests on one HTTP/2 connection still reach that backend. An HTTP/2-aware L7 proxy can distribute separate requests across backends, but it cannot transparently move an active gRPC stream or established WebSocket session.
Application visibility changes the architecture. L7 can send /catalog and /checkout to separate pools, route by hostname, or apply a canary rule using a header. L4 cannot make those decisions from transport metadata alone, so routing must happen elsewhere, such as in a downstream proxy or the application.
TLS placement determines what the balancer can inspect. With L4 passthrough, backends terminate TLS and the balancer does not see HTTP content. To route encrypted HTTP by path or headers, an L7 proxy terminates client TLS; it can establish a separate TLS connection to the backend. That creates two encrypted hops, not one uninterrupted client-to-backend TLS session.
L7 offers a richer policy point but adds responsibilities. Request limits, authentication checks, access logs, and retries may be available, depending on the product and configuration. Parsing, buffering, TLS, and policy evaluation consume resources, while retries can amplify overload or duplicate writes. L4 has fewer application-level controls, but its capacity and latency still depend on implementation and workload.
Choose Layer 4 when
- You need to distribute TCP traffic for a protocol the available L7 proxy does not understand.
- Backends must terminate the original client TLS session, and the balancer does not need HTTP routing rules.
- You need UDP flow distribution and have selected an implementation that supports it.
- You only need transport-level distribution, and application routing or policy enforcement already happens elsewhere.
Choose Layer 7 load balancing when
- Several HTTP services share an endpoint and need host- or path-based routing.
- Canary releases or tenant routing depend on request headers, cookies, or other application fields.
- You need centralized HTTP request metrics, request limits, or integration with authentication and application security controls.
- Many independent HTTP/2 or unary gRPC requests share a small number of client connections, and connection-level balancing would be too coarse.
A worked example
Routing a retail API to separate service pools
Suppose a retail API receives 12,000 requests per second: 9,000 for /catalog and 3,000 for /checkout. The design calls for 12 catalog instances and 6 checkout instances, each scaled independently. An L7 proxy can inspect the path and send each request to the correct pool, including separate requests arriving over one HTTP/2 connection. An L4 balancer alone cannot choose those pools by path; it would need a downstream router or separate endpoints. If checkout also supports a long-lived gRPC stream, that stream stays on its chosen backend. Deployment therefore needs connection draining and client reconnection behavior, not just a new balancing rule.
In the interview
- Start with the protocol and balancing unit: HTTP requests, unary RPCs, long-lived streams, raw TCP, or UDP. Explain why balancing connections is or is not sufficient.
- Draw the TLS boundaries. Identify who owns certificates, where plaintext exists, and whether backend encryption or client certificate identity must be preserved.
- Explain long-lived connection behavior. Expect questions about idle timeouts, connection draining, reconnect storms, and why adding servers does not move existing connections automatically.
- Separate routing from safe failure recovery. Define health checks, timeouts, and retry budgets, and require idempotency before retrying operations that can cause side effects.
- You can use both: an L4 tier can distribute connections across L7 proxies, which then route requests to services. Justify the extra tier rather than adding it by default.
Common mistakes
- Claiming L4 is always faster by a fixed amount. Measure the actual implementation, TLS configuration, traffic shape, and enabled policies.
- Saying L7 can rebalance every message in an established WebSocket or gRPC stream. The stream remains tied to its selected backend.
- Treating TLS termination as unique to L7. Some transport proxies terminate TLS without HTTP-aware routing; the distinction is application awareness.
- Assuming an L7 retry makes a failed write safe. A backend may have committed the write before its response was lost.
Where it comes up
Interview questions where choosing between Layer 4 and Layer 7 load balancing comes up.
- Design a chat app like WhatsAppLong-lived client connections make backend affinity, connection draining, and reconnect behavior central to the load-balancing choice.
- Design a URL shortener like BitlyThe public HTTP entry point requires a clear choice about TLS termination, redirect request routing, and request-level observability.
- Design a login and authentication systemTLS boundaries and application-aware controls matter when routing login traffic and protecting password verification capacity.
- Design Google DocsPersistent editing sessions require distinguishing initial connection routing from document ownership and ongoing collaboration traffic.
Questions people ask
What is the main difference between an L4 and L7 load balancer?
An L4 load balancer selects backends using transport-level information, such as IP addresses and ports. An L7 load balancer understands an application protocol and can route individual requests using fields such as HTTP paths or headers.
Is Layer 4 load balancing faster than Layer 7?
L4 generally does less application processing, but that does not establish a universal latency or throughput advantage. Hardware, proxy architecture, TLS work, connection reuse, and enabled policies all affect the result. Choose the required behavior first, then validate capacity and latency under representative traffic.
Should I use L4 or L7 for WebSockets and gRPC?
Either can work if the implementation supports the required transport and protocol behavior. L7 is useful for routing the initial WebSocket handshake or individual gRPC calls, while L4 can distribute encrypted connections without inspecting them. Neither automatically redistributes an established WebSocket session or active gRPC stream across backends.