Day 23: Load balancing, reverse proxy, CDN, firewalls, VPN
The last hops before your request hits an app
L4 vs L7 load balancing
L4 load balancing distributes traffic based on transport-layer info only (source/destination IP and port) — fast, simple, protocol-agnostic. L7 load balancing actually reads the application-layer content (HTTP path, headers, cookies) to route smarter — e.g., sending /api/* to one service and /static/* to another — at the cost of more CPU work per request.
LB algorithms
- Round-robin — cycle through servers in order; simple, ignores current load
- Least connections — send to whichever server currently has the fewest active connections
- Consistent hashing — map requests to servers by a hash (e.g. of client IP or a cache key) so the same key routes to the same server, minimizing cache misses/reshuffling when servers are added or removed
Reverse proxy
A reverse proxy sits in front of your servers, accepting client requests on their behalf and forwarding to the right backend — centralizing TLS termination, caching, and routing so individual app servers don't each have to implement it.
CDN internals
A CDN is, structurally, a globally distributed reverse-proxy-plus-cache: it terminates connections close to the user (shortening the network hop from Day 1's latency table) and serves cached content directly from an edge location, only reaching back to your origin server on a cache miss.
Firewalls & VPN
A firewall allows or blocks traffic based on rules (source/destination, port, protocol) — the network-level analogue of the file permissions from Day 7. A VPN creates an encrypted tunnel between two points over an untrusted network, making a remote network segment behave as if it were locally reachable — commonly used to reach private cloud resources (Phase 20's VPC) without exposing them to the public internet.
Key terms
- L4 load balancing
- Routing based on transport-layer info only (IP/port).
- L7 load balancing
- Routing based on application-layer content (HTTP path, headers, cookies).
- Consistent hashing
- A hashing scheme that minimizes redistribution of keys when the set of servers changes.
- Reverse proxy
- A server that forwards client requests to backend servers on their behalf.
Capstone: narrate "what happens when you type google.com"
This is a real, frequently-asked interview question — and after this phase you can answer it with genuine depth. Narrate, out loud or in writing, for about 15 minutes: DNS resolution (Day 18) → TCP three-way handshake (Day 16) → TLS handshake and certificate validation (Day 21) → the HTTP request and response, including any caching (Day 20) → and, if relevant, the load balancer/reverse proxy/CDN hops (today) the request passes through before reaching an actual application server. Record yourself or write it out — this becomes both a STAR-adjacent interview asset and a Track A blog post.
The Four Questions: TLS (or L7 load balancing)
Worked example for Docker (from the roadmap): dependency hell → consistent runtime environments → VMs too heavy → shared kernel, weaker isolation. Apply the same four-question shape to TLS: what problem did it solve, why couldn't plain HTTP solve it, and what trade-off (CPU overhead, certificate management) does it introduce?
Phase 2 complete — you should now be able to
Why can consistent hashing reduce cache misses compared to plain round-robin when scaling a fleet of caching servers up or down?
