Checkpoint: Load Balancing & Traffic

Eight lessons ago, the front door was one sentence: put a box in front and spread the traffic. Look at what it is now. You can make that box fast and blind (L4) or smart and reading (L7). You can make it spread by count, live load, two random peeks, or a hash. You can let it pin a user to one server — and you know exactly what that pin costs. It keeps a health roster and routes only to the living; it can say no, politely, at 429-speed; and one level up, GeoDNS and anycast play the same game with continents instead of servers.

That's a lot of machinery — and here's the thing this checkpoint exists to prove: none of it is a feature list to memorize. It's a decision kit. Layer, algorithm, stickiness, health checks, global routing, rate limiting: six dials, and the right setting for every one of them depends on the business standing behind the door. The same six questions produce completely different front doors for a bank, a game, and a flash sale.

So no new ideas today. Instead: three real businesses, eighteen decisions, and you in the architect's chair. If §5 stuck, you won't be remembering answers — you'll be deriving them.

Three scenarios, each a business you've effectively met across this section: a fintech public API (bursty browser clients, microservice paths, EU data-residency law), a real-time multiplayer game (UDP, players worldwide, a dead region mid-match is a catastrophe), and a legacy shop with carts in server memory, one week from a flash sale it cannot re-architect for.

For each one, set all six dials — layer, algorithm, sticky, health check, global, rate limiter — and watch the topology you're designing draw itself live, requests flowing through it. Then check your setup: every slot comes back green or red with the reason, and the reasons are the section's sharpest edges. Watch especially for the traps you've been warned about: the deep health check that looks diligent and ejects a fleet, the sticky session that's a legitimate bridge in exactly one of these scenarios, the latency-routing choice that quietly breaks the law, and the scenario where the honest global-routing answer is don't.

Eighteen decisions. Same six questions every time — and three very different correct doors.

Crossing this checkpoint means the front door is yours. Concretely, you can now:

• Choose a layer on purpose — L7 as the default for anything HTTP (paths, cookies, TLS, WAF), L4 when the protocol isn't HTTP or microseconds matter, and both stacked when you want speed outside and brains inside.
• Match the algorithm to the unevenness — round-robin when requests and servers are uniform, least-connections or power-of-two when they aren't, hashing only when the same client must land on the same box.
• Use stickiness like a professional — which mostly means not using it, and recognizing the one honest case: a bridge for state you can't externalize yet, with an exit plan.
• Keep a health check from becoming the outage — shallow probes, thresholds with hysteresis, and the reflex to ask "what happens to this check when the database blips?"
• Route the planet — geolocation when law demands determinism, latency when speed is the goal, anycast when failover must be measured in seconds, and layers of both in real systems.
• Say no cheaply — a token bucket for bursty humans, a leaky bucket for fragile machines, and a 429 with Retry-After instead of a fleet-wide meltdown.
• Name the boundary — everything above arranges capacity. When the pool is genuinely full or genuinely gone, the front door's job is over, and the answer lives behind it.

The section in six lines — the ones worth keeping forever:

• A load balancer's power is bounded by what it can see (the layer), and its wisdom by what it measures (the algorithm). Blind-and-fast or reading-and-smart is a choice, not a ranking.
• Bursts are the whole game. Algorithms differ at the edges: uneven requests break round-robin, boundary bursts break fixed windows, and every limiter is an answer to "what happens to a burst?"
• Health checking makes a system self-ejecting, not self-healing. Shallow checks, thresholds, panic mode, and retry budgets are what keep self-ejecting from becoming self-destructing.
• Sticky sessions hide statefulness; they don't remove it. Bridge, not destination.
• Global load balancing is the same roster idea at continent scale — and it only removes the single-region SPOF if the data went multi-region too.
• Routing never creates capacity. The most beautifully balanced, health-checked, rate-limited front door in the world still opens onto whatever you actually built behind it.

And that's exactly where the course goes next: through the door. The servers are healthy, the traffic is spread — now, what do those servers actually say to the world? Contracts, verbs, versions, and the art of an interface that survives its own success: §6, APIs.