Load Balancer Types

A load balancer is a reverse proxy that owns one virtual IP (the VIP) and, for every arriving connection, decides which real backend gets it — so the eight "types" you see listed are really answers to two independent questions: WHERE the decision runs (a dedicated appliance, software on a general server, or a managed cloud service) and HOW DEEP into the packet it reads before deciding (a DNS name, the connection 5-tuple at Layer 4, or the full HTTP request at Layer 7). The 5-tuple is source IP, source port, destination IP, destination port, and protocol; you'll also see "4-tuple" when the protocol is fixed — e.g. within a TCP connection — but this guide uses 5-tuple.

Memorising eight silos teaches you nothing; the real exam question is which point on those two axes fits your traffic. Below is the catalog organised that way, and then the distinction that actually carries weight in an interview and in production — L4 vs L7 — traced byte by byte on one real request.

Axis 1 — WHERE it runs

These are not exclusive to a layer: a cloud NLB is an L4 device, a cloud ALB is an L7 device, and HAProxy/Envoy do both. "Hybrid" load balancing is just the normal reality of stacking these — see the closing model.

Axis 2 — HOW DEEP it reads

DNS and GSLB decide once, at name-resolution time, and are coarse. L4 and L7 decide per connection/request. The L4-vs-L7 line is the one worth internalising, so trace it.

What each layer is physically allowed to read

Both layers see the same bytes arrive on the wire. The difference is how far in they are permitted to look before the traffic is encrypted or the decision must be made.

Traced: the same request, L4 then L7

Client 203.0.113.7:51000 opens an HTTPS connection to the VIP 198.51.100.10:443 and sends GET /api/orders/42 with Host: shop.example.com and Cookie: sid=abc123. Two backends exist: an API pool and a static pool.

Through an L4 balancer (e.g. AWS NLB, IPVS)

1. The TCP SYN arrives for 198.51.100.10:443. The LB computes hash(5-tuple: src IP, src port, dst IP, dst port, protocol) (or picks by least-connections) and lands on backend B2 = 10.0.1.6:8443.
2. It rewrites the destination (DNAT) to 10.0.1.6:8443, forwards the SYN, and records the flow in its connection table so every later segment of this 5-tuple goes to B2.
3. The TLS handshake happens end-to-end between the client and B2. The LB holds no certificate and sees only ciphertext.
4. All of GET /api/orders/42 rides inside that one pinned connection. The LB never learns the path or the cookie.

Decision made from ~40 bytes of header, in microseconds, with zero crypto cost on the LB.

The walk above is the NAT/proxy mode: replies flow back through the LB, so its NIC pays for both directions. High-volume L4 tiers often use DSR (direct server return) — the LB rewrites only the inbound packet's destination MAC/IP and the backend replies straight to the client — halving the LB's bandwidth bill at the cost of same-L2/tunnel constraints and the backend needing the VIP configured locally; the mechanics live in the Networking at Scale deep dive.

Through an L7 balancer (e.g. Envoy, NGINX, AWS ALB)

1. The LB accepts the TCP connection itself and terminates TLS — it holds shop.example.com's certificate and decrypts the stream.
2. It parses the request line and headers: path /api/orders/42, host shop.example.com, cookie sid=abc123.
3. A routing rule fires: prefix /api/* → api-pool; the sid cookie pins the session to whichever backend already owns it. It selects A3 = 10.0.2.9:8080.
4. It opens (or reuses from a pool) its own TCP connection to A3 and forwards the request over the trusted network.
5. If A3 replies 502, the LB can retry the same request on A4 — the client never notices.

Decision uses full HTTP semantics, at the cost of a TLS terminate, buffering, and a parse on every request.

Pitfalls

• L4 hides the client IP. After DNAT the backend sees the LB's address, not the user's. You need the PROXY protocol (L4) or an X-Forwarded-For header (L7) to recover it — otherwise your access logs, rate-limits, and geo-rules are all wrong.
• L7 makes the LB a crypto bottleneck and a key custodian. Terminating TLS puts your private keys on the balancer and burns CPU per request; a TLS-heavy spike can saturate the LB long before the backends feel it.
• DNS/GSLB failover is slow. Resolvers and clients cache A records past the TTL (and cache negatives too), so pulling a dead node out of DNS can take minutes to hours. Never rely on DNS for fast, health-based failover — use it for coarse geo steering only.
• Sticky sessions create hotspots. Cookie- or IP-hash stickiness sends a big corporate NAT (thousands of users behind one IP) all to one backend, skewing load; and losing that backend drops every session pinned to it.
• GSLB routes on the resolver, not the user. A client using a distant public DNS (say 8.8.8.8) can be steered to the wrong region because GSLB sees the resolver's location, not the user's.
• Hardware has a hard ceiling. An appliance rated for N Gbps cannot elastically absorb a 3× spike the way a software/cloud fleet can — you buy the next box and wait.

When to use which — and the trade-offs

L4 vs L7 (the decision that matters most). Choose L4 when the protocol is not HTTP (gRPC-over-raw-TCP edge, databases, game UDP, MQTT), when you need line-rate throughput and lowest latency, or when you must not hold TLS keys on the balancer (passthrough for compliance). Choose L7 when the routing decision depends on the URL, host, or cookie, or when you want TLS offload, retries, canary splitting, or a WAF. What L7 costs you versus L4: per-request TLS + parse CPU, added tail latency from the terminated hop, and your private keys living on the LB. Crisp rule: choose L4 (AWS NLB, IPVS, MetalLB) when the LB should be a fast, dumb pipe; prefer L7 (Envoy, NGINX, AWS ALB) when it must understand the request.

Hardware vs software vs cloud. Hardware buys peak throughput and predictable latency but a fixed ceiling and capex; software (HAProxy/Envoy) buys elasticity and low cost but you own patching and capacity; cloud (ALB/NLB) buys zero-ops autoscaling but vendor lock-in and reduced control. Choose hardware for high-volume on-prem edges, software when you need control and portability across clouds, managed cloud when ops time is the scarce resource.

DNS/GSLB vs a real LB. DNS and GSLB are for coarse, geographic, first-hop distribution across sites — not for per-request or health-based decisions. Don't pick DNS instead of an L4/L7 LB; pick it in front of one at each region.

Takeaways

• The eight names collapse to two questions: where does the decision run, and how deep does it read. Answer those and the "type" falls out.
• L4 pins a whole TCP flow by its 5-tuple and never sees the payload; L7 terminates the connection, reads HTTP, and can route/retry/rewrite — paying TLS + parse CPU per request.
• DNS and GSLB decide at name-resolution time and are slow to fail over because of TTL caching — coarse geo steering, not health-based routing.
• Production systems layer them: GSLB steers a user to a region, a cloud/hardware L4 device fronts that region, and per-service L7 balancers route inside it. That stack is what "hybrid" really means.

Re-authored and deepened for this guide. Synthesized from the HAProxy and NGINX configuration guides, the Envoy proxy architecture docs, AWS Elastic Load Balancing documentation (ALB as L7, NLB as L4), Cloudflare's Learning Center articles on load balancing and GSLB, and Artur Ejsmont, "Web Scalability for Startup Engineers." The L4/L7 packet walk-through uses illustrative addresses (RFC 5737 documentation ranges) and standard TCP/TLS/HTTP behavior.

Drill ladder — survive the follow-ups

L0 · Load balancers differ by where they run (hardware, software, cloud) and how deep they read (DNS, L4, L7).

L1 · "Why not always use L7 so I can route by URL?"
Bar: L7 terminates TLS and parses HTTP, which costs CPU and adds latency. L4 is faster and keeps keys off the balancer. Use L7 only when you need content-aware routing.

L2 · "A client hits a dead region because DNS still returns its IP. Why?"
Bar: DNS resolvers cache records past the TTL. DNS/GSLB is for coarse geo steering, not fast failover. Pair it with health checks and short TTLs, but expect minutes of propagation.

L3 · "The backend sees the LB's IP, not the client's. Fix it."
Bar: At L4 use PROXY protocol; at L7 use X-Forwarded-For. Without this, rate limits and logs are wrong.

L4 · "Terminate TLS at the L4 LB, at the gateway, or end-to-end?"
Bar: End-to-end is most secure but prevents L7 inspection. Terminate at the gateway for content routing. Terminate at L4 only if you need hardware offload and can propagate client identity another way.

L5 · "Design a stack that survives a whole-AZ failure with sub-minute failover."
Bar: GSLB steers to healthy regions; within a region an L4 LB spans AZs; L7 gateways are stateless behind it; backends replicate across AZs. Keep TTLs short enough to allow re-steering, and use health checks that actually exercise the app.