Layer 4 and layer 7 load balancing
Choose between a balancer that forwards TCP connections quickly and one that reads each HTTP request so it can route by content.
A layer 4 balancer forwards connections without looking inside, and a layer 7 balancer reads the request and decides with what it finds.
Use it when#
L7: you want to route by path, header, or kind of request, or retry a failed call on another server.
L4: raw throughput and low latency matter more than routing, or the traffic is not HTTP.
Either: a single balancer is the busiest node on the board.
How it works#
An L4 balancer works on IP addresses and ports. It picks a backend and passes the bytes along, so it does little work per request and handles very large volumes. An L7 balancer terminates the connection, parses HTTP, and can send /api to one pool and /images to another, add headers, and retry. Real examples are AWS's Network Load Balancer for L4 and its Application Load Balancer for L7.
Splitting pools by kind also isolates them: a flood of page views cannot starve the API servers.
What it costs#
L7 does more work per request, so it has a lower ceiling, costs more per request, and adds latency. L4 cannot see paths or retry a request, and it spreads load by connection, so one long-lived connection can pin a server.
In Quorum#
A Load Balancer has a variant. L7 is the default, and L4 needs L4 load balancing. L4 forwards every kind of request on every Link, so per-kind routing is gone. On an L7 balancer, each Link can carry only some kinds of request.
Drag to pan. Hold Ctrl or Cmd and scroll to zoom.
| Where | Setting | Value | Why |
|---|---|---|---|
| Load Balancer | Variant | l7 | An L7 balancer reads the HTTP request, so it can send a kind of request to the servers built for it. |
| App Server | Instance size | small | Small gives the app two vCPUs, enough to run code while the data tier does its own work. |
| App Server | Instance size | small | Small gives the app two vCPUs, enough to run code while the data tier does its own work. |
| Database | Instance size | small | Small gives the Database two vCPUs, so the figures below reflect the Cache and not a starved Database. |
| Link Load Balancer → App Server | Kinds on this Link | page | Only page views go to this server, so its CPU and memory serve one workload. |
| Link Load Balancer → App Server | Kinds on this Link | read,write,login | API calls go here, so a burst of page views cannot starve them. |
Research this Design needs: Load balancing.
Drag to pan. Hold Ctrl or Cmd and scroll to zoom.
| Where | Setting | Value | Why |
|---|---|---|---|
| Load Balancer | Variant | l4 | An L4 balancer forwards TCP without reading HTTP, so it handles far more traffic for less money. It cannot route by kind or retry. |
| App Server | Instance size | small | Small gives the app two vCPUs, enough to run code while the data tier does its own work. |
| App Server | Instance size | small | Small gives the app two vCPUs, enough to run code while the data tier does its own work. |
| Database | Instance size | small | Small gives the Database two vCPUs, so the figures below reflect the Cache and not a starved Database. |
Research this Design needs: Load balancing, Load balancing algorithms, L4 load balancing.
The glossary defines load balancer. Pair this with Load balancing algorithms.