Part 9 — Modern networking

A tour of what sits on top of everything you've learned. These are overviews, not deep dives — each links to where to go deeper.

Chapter 36 — Load balancers, CDNs, and anycast

The problem

One server can't handle a popular website, and even if it could, it would be slow for people on the other side of the world (Chapter 27: physics).

Load balancers

A load balancer sits in front of several servers and spreads requests between them.

                    +--> server 1
   users --> [ LB ] +--> server 2
                    +--> server 3

Two kinds, and the distinction matters:

	L4 load balancer	L7 load balancer
Decides using	IP address + port only	The actual HTTP request
Can route by	Nothing about the content	URL path, `Host` header, cookies
Sees your data?	No — traffic passes through encrypted	Yes — it terminates TLS and re-encrypts
Speed	Very fast	Slower, but far more capable
Examples	AWS NLB, IPVS, HAProxy in TCP mode	nginx, HAProxy in HTTP mode, Envoy, AWS ALB

Health checks are the important operational piece: the load balancer continuously tests each server (GET /healthz) and stops sending traffic to ones that fail. Getting this right (interval, threshold, what "healthy" means) is most of running a reliable service.

Why you get 502/504 errors: the load balancer couldn't reach the server behind it (502) or waited too long for a reply (504). The error comes from the load balancer, not the server — which is why your application logs may show nothing.

CDNs

A Content Delivery Network puts copies of your content in hundreds of locations worldwide, so users connect to something nearby.

Recall Chapter 4's latency budget: 4 round trips before the first byte. If the server is 90 ms away that's 360 ms; if a CDN edge is 10 ms away it's 40 ms. Same content, 9x faster, purely from distance.

CDNs also: cache static files, absorb traffic spikes, terminate TLS close to the user, and provide DDoS protection.

Anycast

Here's the clever bit that makes CDNs work: the same IP address is announced from many locations at once, and internet routing (BGP, Chapter 13) naturally delivers your packets to the nearest one.

   1.1.1.1 exists in London, Frankfurt, Singapore, Sao Paulo...
   You send a packet to 1.1.1.1 and it goes to whichever is closest to YOU.

This is how 1.1.1.1 and 8.8.8.8 answer in a few milliseconds from anywhere on Earth. It also spreads a DDoS attack across the whole global capacity instead of one data centre.

Practice (15 min)

# See a CDN in action -- ask different resolvers, get different answers
dig @1.1.1.1 www.cloudflare.com +short
dig @8.8.8.8 www.cloudflare.com +short

# See which anycast location answers YOU
dig CHAOS TXT id.server @1.1.1.1 +short        # Cloudflare tells you the city!

# Compare latency to a CDN vs a single-location server
ping -c 5 1.1.1.1
ping -c 5 <a server you know is far away>

# Look at the headers a CDN adds
curl -sI https://www.cloudflare.com | grep -iE 'server|cf-ray|age|cache'