Load Balancing: Layer 4 vs Layer 7

An L4 balancer sees source/destination IP and port — not HTTP paths. A client connects to :443; the balancer picks a backend (round-robin, least connections, or IP hash) and forwards the TCP (or UDP) stream. It does not terminate TLS or read cookies unless you add a separate terminator.

Use L4 for non-HTTP workloads (databases, many gRPC/WebSocket setups) or when you want minimal per-connection work at the edge. AWS Network Load Balancer, HAProxy in TCP mode, and Linux IPVS operate here. Pass the real client IP with PROXY protocol when backends need it.

An L7 balancer understands HTTP(S). It can terminate TLS, read Host, path, cookies, and headers, then route /api/* to the API pool and / to the web pool. That enables host-based vhosts, sticky cookies, rewrites, and WAF hooks. AWS Application Load Balancer, NGINX, and Traefik are common L7 choices.

Request trace: Client → L7 (TLS) → match Host + path → select upstream → proxy → response. In open-source NGINX, max_fails and fail_timeout implement passive checks based on failures from real proxied requests; they do not periodically probe /health. Active HTTP probes require NGINX Plus or another health-checking component.

Many production edges stack both: L4 (or DNS/anycast) at the outer perimeter for connection distribution and DDoS absorption; L7 inside for TLS, path routing, and service dispatch. In Kubernetes a common shape is Internet → cloud LB → Ingress (L7) → Service → Pod. Pure TCP/gRPC or database traffic may stay on L4 services end to end.

Decision evidence: If you only need “spread TCP to N identical nodes,” L4 is enough. If product routing depends on URL, headers, or hostnames, you need L7 somewhere. Measure p95 latency and error rate before and after moving TLS termination — do not assume L7 is “always slower enough to matter” without your workload.

Trigger. db1 behind the HAProxy TCP pool above stops accepting connections — a crash, an OOM kill, a bad deploy. Symptom. For the next few seconds, some client connections still route to db1 and hang or reset, because HAProxy hasn't yet proven the backend is actually down; a health check is a sampled signal, not an instantaneous one.

Root mechanism. The config's fall 2 requires two consecutive failed checks at inter 2s before HAProxy marks a server DOWN — a deliberate debounce against a single dropped packet flapping a healthy server in and out of rotation, at the direct cost of up to ~4 seconds where new connections can still land on a backend that's actually dead. Recovery: once db1 fails its second check, HAProxy removes it from the pool and every new connection routes to db2 only — no code change, no manual intervention, the mechanism the config already declared. Verification: run repeated nc -zv connection attempts through the failure window and confirm they shift from intermittent failures to consistently succeeding against db2 alone once the fall threshold is crossed. Prevention: tune fall/rise/inter against your actual failure tolerance — a lower fall detects failure faster but risks flapping a backend with occasional transient blips; verify the trade-off against a real failure injection, not just the default values from a tutorial.