Reading — step 1 of 5
Read
L4 vs L7 Load Balancing
The OSI layer at which the load balancer makes its routing decision changes what information is available and what features are possible.
L4 (TCP/UDP) load balancing routes based on the 5-tuple: src_ip, src_port, dst_ip, dst_port, protocol. The LB never inspects the bytes. Cheaper, faster,
and protocol-agnostic — works for TCP, UDP, anything.
client --SYN--> LB --SYN--> backend_X (chosen by hash(5-tuple))
<--SYN-ACK-- ...
L7 (HTTP/2/gRPC) load balancing parses the application protocol and routes based on:
- HTTP method (POST -> writeable backend, GET -> read replica)
- Host header (
api.example.com-> upstream A,app.example.com-> upstream B) - Path prefix (
/api/v1/*-> v1 service,/api/v2/*-> v2 service) - Headers (
X-Tenant: pro-> premium pool) - Cookies (sticky sessions, canary releases)
| Aspect | L4 | L7 |
|---|---|---|
| Speed | very fast (kernel-bypass) | slower (parse HTTP, allocate) |
| Connection | one TCP through to backend | LB terminates, opens new to backend |
| Protocol | any TCP/UDP | HTTP/HTTPS/HTTP2/gRPC only |
| TLS | can pass through | usually terminates |
| Header routing | impossible | core feature |
| Retries | cannot retry (connection) | can retry safely |
| Examples | HAProxy mode tcp, AWS NLB | NGINX, Envoy, AWS ALB |
Routing precedence in L7: longer path prefix wins; among same-prefix rules, exact host match beats wildcard. (NGINX, Envoy, Istio all follow this.)
In this exercise you implement both: an L4 picker (deterministic hash of source IP+port) and an L7 picker (longest-prefix-match with host).
Discussion
Ask a question, share an insight, or help someone who’s stuck.
Sign in to post a comment or reply.
Loading…