Name: System Design Masterclass
Availability: InStock

The last lesson, on path-based routing, kept many services behind one name and split them by path. Picture five services behind example.com, split by path in that way. This lesson gives each one its own name.

The routing rule is almost identical. The reads a field and picks a backend. Everything else changes.

A five-row comparison of by path and by hostname. The address: example.com slash app, versus app.example.com. The browser origin: one shared by everything, versus one per service. Cookies: every service sees them all, versus each service has its own. The certificate: one name to cover, versus one name each or a wildcard. DNS: one record, versus one record per service. — FigureFigure 1. Moving a service from a path to a hostname changes five things
Only the first row is routing. The other four are the reason this decision is much harder to reverse than a routing rule.

That is the honest framing for the whole lesson. Host routing is not a tidier way to arrange the same thing. It draws a boundary the browser will enforce for you, and it takes on a record and a certificate for every name you draw.

Start with the mechanical part. Here is a small server with three names configured, a wildcard, and a default for anything else.

A recorded terminal session. Configured names app.example.com and api.example.com match exactly. APP.EXAMPLE.COM, app.example.com with a trailing dot, and app.example.com:8443 all match exactly too. docs.example.com matches the wildcard with one label. a.b.example.com, example.com, evil.test and a request with no Host header all fall through to the default server. — RecordedFigure 2. Three configured names, a wildcard, and everything else
The three spellings in the middle block all reach the product, and all three are legal .

Those spellings are worth being explicit about, because a matcher that misses one of them treats several requests for one site as several different sites.

Five ways a client can write one hostname. APP.EXAMPLE.COM: hostnames are case insensitive, so lowercase it. app.example.com colon 8443: the port may be attached, so cut at the colon. app.example.com with a trailing dot: a trailing dot is the DNS root label, so strip it. No Host header at all: legal in HTTP/1.0 and bots send it, so the default server. Two Host headers: reject the request. — FigureFigure 3. Five ways a client can write one hostname
Four of these are legal and have to be normalised. The last is an attack, and the only correct response is to refuse the request.

The duplicate Host header is worth a sentence of its own. If two components in your chain pick different Host headers from the same request, one of them routes and the other one authorises, and they are working on different requests. Modern servers reject duplicates. Check that yours does instead of assuming it.

Now the wildcard, which is where most of the surprises live.

A hand-drawn diagram. The rule is star dot example.com. docs.example.com, one label in front, matches. a.b.example.com, two labels in front, does not match. example.com, no label in front, does not match either. A note reads: a wildcard covers exactly one label, and never the bare name. — SketchFigure 4. A wildcard reaches exactly one label deep
This is the rule for certificates and the rule for virtual hosts, and it catches people in both places.

The common version of this is a certificate bought for *.example.com that turns out not to cover example.com, discovered the first time somebody types the address without the www. Ask for both names. The same applies to your routing table: *.example.com and example.com are two entries.

The deeper case is worth knowing before you design a naming scheme. If you plan on service.team.example.com, one wildcard will not cover it. You need a wildcard per team, or a name per service.

Host-Based Routing

The rest of this lesson

Continue this lesson

The Same Services, Addressed Differently

What Counts as a Match