Module 1 of 5
Thinking in invariants
Before any boxes and arrows: what the system promises, which states it may be in, how much load it must carry, and how to choose between designs and write the choice down.
Most design reviews start with a diagram. This module starts one step earlier, with the promises the diagram is supposed to keep. A promise you can state as an invariant can be checked by code, in tests and in production. A promise you cannot state that way, such as “fast” or “secure”, stays a matter of opinion until it fails in production.
The four lessons build the habits the rest of the course relies on: rewriting requirements as safety and liveness properties, modeling entities as explicit state machines whose illegal transitions are bugs, estimating capacity with arithmetic before choosing an architecture, and recording tradeoffs so that a later measurement can overturn them. Afterwards you should be able to take a vague brief and turn it into a short list of checkable promises, a state diagram, a capacity estimate, and a decision record that says what would change your mind.
Lessons
- 1.aWhat a design promisesHow do you turn vague requirements into promises a system can be checked against?20 min
- 1.bState machines and transitionsWhy model entities as explicit state machines, and how do you find the illegal transitions?19 min
- 1.cBack-of-the-envelope capacityHow do you estimate load, storage, and latency before building, and why does a busy server get slow so suddenly?20 min
- 1.dTradeoffs and decision recordsHow do you reason about tradeoffs honestly, and record a decision so it can be revisited?21 min