System Design Foundations

System design is usually taught with boxes and arrows and graded with adjectives. This course does neither. You build one service on your own lab machine — an order platform for a synthetic wholesale grocer — and every design decision in it is made, implemented, measured and written down, in that order. You start by writing requirements with objectives that have indicators, targets and windows, and a load estimate derived from the business rather than from a benchmark. Then you write a load generator that keeps its raw results, and you take a baseline. From then on, nothing is asserted. An index is added because the page query was measured before and after. Work is moved to a queue because the two designs were measured against each other with the partner answering slowly. A cache is added because the read-to-write ratio justifies it and the measurement shows what a hit actually saves — and the cache is proved to serve one database query for twelve concurrent readers rather than twelve. Failure is taught by causing it. You make the shipping partner hang and watch a request that has no deadline; you add the deadline, the bounded retry budget with jitter, the circuit breaker and a degraded answer, and then you make it hang again and watch the difference. You spike the service above its concurrency limit and require it to refuse work with `Retry-After` while liveness keeps answering. You let a message exhaust its retry budget into a dead-letter table and then replay it. You hold a lock open while a migration runs, and find out what a `lock_timeout` is for. You pause WAL replay on a read replica so the stale read is a fact rather than a race. You stop an instance in the middle of a polling test. The written work is graded as written work: requirements, decision records, a capacity plan that names cost levers instead of inventing cost figures, a change record, a runbook, a review of somebody else's flawed proposal where every finding is reproducible, and a design document. The last thing you build is an acceptance suite for your own design — and you run it against a deliberately broken copy of the service, because a suite that passes on both proves nothing.