How a Request Finds You

01The Journey of One Request

Sometime this week — probably closer to the deadline than you planned — you will send a friend the URL of your Project 1 service. They will type it on a phone, on a bus, on a network you have never heard of, and about half a second later your page will appear. These notes are about everything that happens inside that half second.

Before your code runs a single line, that request will have crossed a phone book, possibly a copy shop, a front gate, a host with a seating chart, at least one bouncer, and two streets. Here is the whole trip. Each stop is one section of these notes, and in §07 you drive the trip yourself, leg by leg — and then break it on purpose.

Why now? Notes 02–03 gave you machines — rented muscle. Notes 04 gave you storage — rented memory. But a server no one can reach is a very expensive space heater. Networking turns a machine exists into a person on a bus can use it — without also turning it into anyone on earth can rummage through your database. Two jobs, pulling in opposite directions: findable to the people you invited, invisible to everyone else.

02Your Private Neighborhood

Start at the destination and work backwards. Your servers do not stand naked on the public internet. They stand inside a VPC — a virtual private cloud. The picture to hold: a gated office park that you rent. The provider owns the land and the buried cables; everything inside the fence is yours — your address plan, your streets, your gate. Thousands of other tenants’ parks share the same physical land, and not one packet of their traffic ever drives inside yours. AWS and Google Cloud both call it a VPC; Azure calls it a Virtual Network. Same fence.

Every machine in the park gets a street address: an IP address, four small numbers like 10.0.1.21. Notice the 10. Addresses starting with 10., 172.16.–172.31., or 192.168. are reserved for use inside private networks. They never appear on the public internet, so every park on earth reuses them freely — yours and a stranger’s can both contain a 10.0.1.21 the way two towns can both have a Main Street. The park itself typically owns just one or two public addresses, and they live where you would expect: on the front gate.

Inside the fence, you lay out streets. A subnet is one street — a slice of your address plan, such as “all the 10.0.1.x addresses.” And streets come in exactly two kinds. On a public street, a building may have a front door facing the internet — a public address of its own, reachable from outside. Web servers live here, because being reachable is their whole job. On a private street, no building has a front door at all. Not locked doors — no doors. The database lives here, along with anything else that should only ever be spoken to by other buildings in the park. The internet cannot reach a private-street building even by accident, because there is nothing on the outside wall to knock on.

One console surprise to expect: a street belongs to exactly one availability zone (Notes 01), so a real park has this picture photocopied per zone — for the same reason storage kept copies.

03Signposts and Doors

Two questions remain about the park: how traffic finds its way around, and who gets into each building. Different questions, different machinery.

3.1 Route tables — the signposts

Every street has a signpost at the corner: a route table. It is a short list of directions of the form “mail addressed to there goes that way.” The public street’s signpost has two lines: addressed to somewhere in the park (10.0.x.x) → stay on the local roads, and addressed to anywhere else → the front gate. The private street’s signpost has the first line and simply omits the second. That is the entire difference between the two kinds of street: one missing line. A street is not private because of a lock; it is private because its signpost has nothing to say about the outside world.

One refinement, because the database still needs its security updates: a NAT gateway is a one-way revolving door — private buildings can call out through it (fetch a patch), but nobody can use it to call in.

3.2 Security groups — the bouncers

Signposts decide where traffic can drive. A security group decides who gets into a building. Picture a bouncer at each building’s door holding a guest list — and starting from a hard default: nobody gets in. Every line you add to the list opens exactly one door to exactly one crowd. The doors are ports — numbered, thousands per building, with meanings the world has agreed on: padlocked web traffic knocks on 443, plain web on 80, remote login on 22, a Postgres database on 5432. AWS says security group, Google Cloud says firewall rules, Azure says network security group. Same bouncer.

The best line you can write on a list names a crowd instead of an address: the database’s list says “anyone wearing a web-building badge, door 5432” (anyone in the web servers’ own group). So when the autoscaler hires a third web server at 2 a.m., it is born wearing the badge and is on the list from its first breath. No list edits, ever.

Now be the bouncer for a minute. The toy below has both lists as toggles. Flip rules on and off, fire test requests at the buildings, and read the one-line verdicts — especially the two that go wrong in opposite directions.

04One Address, Many Servers

Notes 03 left a loose end, on purpose. The autoscaler hires and fires web servers by the minute, and each new server is born at a new address. But your visitors hold exactly one URL. Who reconciles the one name with the changing many?

The load balancer — and the picture to hold is a restaurant host. Diners do not pick tables; the host seats them wherever there is room. Your visitors all arrive at one address — the load balancer’s — and it forwards each request to whichever web server is alive behind it. Tables come and go all evening; the front desk never moves. AWS calls it an Application Load Balancer, Google Cloud says Cloud Load Balancing, Azure says Application Gateway.

The host’s quiet superpower is the health check. Every few seconds, the desk pings every table: everything all right over there? A server that stops answering is simply taken off the seating chart — no alarm, no ceremony, and no diner ever sent to a broken table. When it recovers, or the autoscaler replaces it, it quietly rejoins the chart. Your visitor never learns any of this happened.

And notice how neatly the host and Notes 03’s hiring manager divide the work: the load balancer seats, the autoscaler staffs. New hires join the chart the moment they pass their first health check; servers being let go are seated last, finish their diners, and are struck off. Two robots, one dining room, neither needs you awake.

One more job happens at the desk, and it is the one your friend can see: the padlock in the browser bar. TLS termination means the front desk holds your certificate — the document proving yourservice.dev really is you — and does the proving and the unwrapping of the encrypted envelope for every request. The tables never touch certificates; they receive requests over the park’s own streets. This is where Project 1’s padlock lives: every provider issues and auto-renews a certificate free, provided it lives on their load balancer. Attach it, redirect door 80 to door 443, done.

05The Phone Book

Rewind to the very first moment of the trip. Your friend typed yourservice.dev — a name. But every leg you have seen so far runs on numeric addresses. Something has to turn one into the other, and that something is DNS: the internet’s phone book. Not one big book — a web of phone books quoting each other, which is what makes it fast and occasionally confusing.

The lookup is a set of steps a person can follow:

• The browser checks its own notes first. Looked up recently? Use the address written down. Done, in a microsecond.
• Otherwise it asks its resolver — a librarian, usually the phone company’s, whose whole job is looking things up for you. She checks her notes too.
• If nobody has notes, the librarian asks around: the root directory (“who keeps the .dev book?”), then the .dev registry (“who keeps yourservice.dev?”), then your DNS host, which finally answers.
• The answer travels back with a time-to-live — a TTL, a note that says “trust this for 300 seconds.” Everyone along the way pencils it in for exactly that long. The next thousand lookups never leave step one.

The penciled-in notes explain a mystery every student hits this exact week: “I changed my DNS and nothing happened.” Nothing is broken. The world is full of phone books still holding your old address, each entitled to trust it until its TTL runs out — change spreads by expiry, not announcement. The practical move: the day before a switch, lower the record’s TTL to sixty seconds; change; raise it back. You cannot rush old notes, but you can arrange for them to be short-lived.

Two kinds of entry cover this course. An A record: “this name means this numeric address.” A CNAME: “this name is an alias for that other name — look that one up instead.” The second is what Project 1 wants: point your domain at the load balancer’s name (a CNAME or your provider’s “alias”), never at a machine’s address. Machines are cattle; their addresses change when the autoscaler blinks. The front desk is the one thing in your park with a permanent name.

06Copies Near You

Notes 04 manufactured durability out of copies. Those copies have cousins, built from the same trick for a different prize: speed. The problem: your park lives in Virginia, so a Tokyo visitor’s request must physically cross the planet and come back — a fifth of a second, laws-of-physics case — and a page of dozens of files pays that toll dozens of times. Your site is not slow because your code is slow; it is slow because the Pacific Ocean is wide.

The fix: stop making Tokyo cross the ocean. A CDN — content delivery network — is a chain of copy shops in dozens of cities worldwide. The first visitor in Tokyo pays the full trip: the request goes all the way to your park (the origin), and on the way back the Tokyo shop keeps a photocopy on its shelf, marked — you know this word now — with a TTL. The next thousand Tokyo visitors are served from around the corner, and your servers never even hear about them. Cheaper, too: egress was Notes 01’s ugliest bill line, and requests answered at the copy shop never touch your origin. CloudFront on AWS, Cloud CDN on Google, Front Door on Azure.

Now the honest limits. A copy shop can only sell what can be photocopied in advance: images, CSS, fonts, video — the coats from your Notes 04 bucket, which is why bucket and CDN are sold as a pair. What it cannot do is answer “what’s in my cart?” — a page composed fresh for one person, from your one database, has no pre-made copy. Static assets fly; the dynamic heart of your app still makes the full trip. (And a CDN in front of one slow database is a lobby in front of one slow elevator.)

One last connection, and the week snaps shut. A shelf full of photocopies is exactly the “copy you forgot you had” from Notes 04’s stale-read story — the CDN is eventual by design, and no provider will change that. Which is why the rule you already adopted is the whole cure: never change a file behind a URL; ship style.v2.css and point to it. A copy shop cannot hand out a stale copy of a file it has never heard of.

07The Journey, Re-run

You now hold all six legs. Run the trip end to end — then break it, because this system is at its best the moment a leg fails and the request simply… routes around the damage. Defaults first; then take Web 1 down, expire the phone books, ask for a static image, and watch how far the trip even bothers to go.

Notice three things on the way through. The static-image trip is two legs long — most of a well-built site’s traffic never reaches your park at all. The dead server changes nothing your friend can see. The cold phone book costs one slow lookup, once. None of that is luck; all of it is configuration you chose.

08Before Session 9 — October 5

Project 1 is due at the end of this week. You are closer than it feels: the compute runs, the bytes live in the right shapes, and these notes were the final wiring. Here is the submission checklist, ordered to avoid waiting on other people’s phone books. It remembers your progress on this device.

• Point your name at the front desk, today. A CNAME (or alias) from your domain to the load balancer’s name — never a machine’s numeric address. Do this first: DNS is the one step with a built-in waiting period — start it Monday, not Friday night.
• Hang the padlock. Provider-issued certificate attached to the load balancer, and door 80 redirecting to door 443. Then load your site and enjoy the padlock — you built that.
• Audit the park with this week’s eyes. Database on a private street; bouncer lists that open only 443 to the world; door 22 restricted to your own address or closed. Fire Plate 3.2’s four tests at your real architecture, in your head, and expect the same four verdicts.
• Test the live endpoint from off your own network — phone on cellular data, or a friend in another city. “Works from my laptop” fools someone every year — your laptop’s phone books and caches are warm in ways a stranger’s are not.
• Draw the architecture diagram. It is Plate 7.1 with your labels on it: streets, gate, front desk, buildings, bucket, and the bouncer list on each door. If a resource exists in your account but not in your diagram, one of the two is wrong.
• Finish the cost estimate at three traffic levels. This week added two lines to it: the load balancer’s hours, and the egress your CDN saves. Cite the pricing page and the region, as Notes 01 asked.
• Submit: live URL, diagram, cost estimate, and the repo link, via Brightspace. The report explains and defends — day one’s standard: if it runs but you cannot say why it is built that way, it is not finished. Commit history should show the road, not one heroic Friday push.

09Key Terms

VPC / Virtual Network

Your gated office park: a private slice of the provider’s network with its own address plan, streets, and gate. VPC on AWS and Google; VNet on Azure.

Subnet

One street inside the park — a slice of the address plan. Comes public (front doors allowed) or private (no front doors).

IP address

A machine’s street address, like 10.0.1.21. Ranges starting 10., 172.16–31., and 192.168. are private — reused inside every park, never seen on the public internet.

Internet gateway

The park’s front gate: the single crossing to the public internet.

Route table

A street’s signpost. A private street is private because its signpost has no line for the front gate.

NAT gateway

The one-way revolving door: private buildings call out through it; nobody calls in.

Security group

A building’s bouncer: deny by default, each line opens one door to one crowd. Firewall rules on Google; network security group on Azure.

Port

A numbered door on a building. By convention: 443 https, 80 http, 22 remote login, 5432 Postgres.

Load balancer

The restaurant host: one permanent address in front, requests seated across whichever servers are alive behind it.

Health check

The host’s every-few-seconds ping. A server that stops answering silently leaves the seating chart.

TLS termination

The padlock handled at the desk: the load balancer holds the certificate and unwraps the envelope; servers never touch certificates.

DNS

The internet’s phone book: names to addresses, via a chain of books that quote and cache each other.

Resolver

The librarian doing lookups on your behalf, penciling answers into its notes. Usually your ISP’s.

TTL

How long a cached answer may be trusted. Why DNS changes “take a while”: change spreads by expiry, not announcement.

A record / CNAME

A: “this name means this address.” CNAME: “this name is an alias for that other name.” Project 1: CNAME/alias to the load balancer.

CDN

Copy shops in dozens of cities holding TTL-stamped copies of your static files. The first visitor per city pays the full trip; the next thousand don’t.

No term matches that filter.