One Slow App, Every Layer

"Why is this app slow?" is a question with a floor on every level of the course — and diagnosing it top to bottom is the whole curriculum working as one instrument.

A rider complains the transit app lags. Start at the top: is the algorithm the problem? A route search that grew from a city to a region may have crossed a growth boundary — the order-of-growth lesson (0128): the code didn't change, N did, and a shape that was fine at small scale is presenting its bill, exactly as the theory unit priced it (0161). One layer down: the language and its implementation (0381) — interpreted paths, unoptimized builds, a missed compiler stage. Below that, the operating system: the app's process may be losing its scheduling turns to a noisy neighbor (0305), or blocking on events (0306) more than it runs. The memory hierarchy has its own suspects (0257): a working set that outgrew cache, locality lost to a careless data layout (0261), page faults where hits used to be (0314). Then the wire: every feature that quietly became a full request-response round trip (0542) instead of a small exchange (0545) added its latency. The database contributes its classics — a query missing the key structure it needed (0421), a transaction holding isolation longer than the design intended (0426). And in the cloud, the orchestrator (0555) may be scaling exactly as configured, which is not the same as correctly. The diagnosis discipline is the course in miniature: name the layer, test the layer, clear the layer — because "slow" is never one fact; it is a stack of possible facts, each with a unit behind it.