Course contents
On this page
Lesson plan 01: Workloads and correctness contracts
Translate product behavior into invariants, access patterns, skew, and measurable success boundaries.
The guided lesson now introduces one mechanism. This original plan covers the wider topic; follow the deeper-reading links at the end of the guided lesson for the remaining material.
Placement: Part 1: Foundations: understanding work, time, and resources.
Prerequisites: Basic programming and SQL; no systems background required.
Learning outcomes
- Translate product behavior into invariants, access patterns, skew, and measurable success boundaries.
- Distinguish independent transactions from competing operations on a shared ownership invariant.
- Explain why active connections, useful transactions per second, and delivered updates are separate capacity measures.
- Separate a general mechanism, a documented implementation choice, and an illustrative numerical assumption.
Teaching sequence
- Establish the motivating situation: A flash sale concentrates most writes on one inventory record while the rest of the catalog stays idle.
- Introduce the vocabulary and the correctness obligation before an optimization. Define OLTP, OLAP, mixed workloads.
- Develop the mechanism: Separate business arrivals, attempts, successful commits, and changes delivered; establish the ownership and stock invariants before choosing a topology.
- Follow the complete worked example: 100000 requests/s with 60% directed to one key creates 60000 hot-key requests/s. Explain the assumptions, intermediate units, and limiting interpretation.
- Extend the scenario to changed load, skew, or failure, explaining skew, contention, invariants, workload envelopes.
- Connect the mechanism to a documented implementation and an alternative with a different workload fit. Close by stating the remaining cost and the next lesson dependency.
Required chapter material
Use a complete execution trace or worked calculation, supported by an annotated static diagram or table. Include language-neutral pseudocode or labeled SQL when it clarifies the mechanism. State preconditions, ownership, visibility, and failure boundaries for algorithms. Describe operational costs as well as the normal path. All questions raised in the narrative must be resolved in the text.
Visual explanation
A request-to-outcome path labels the authoritative decision, acknowledgment, and visible result; a workload table separates average traffic from its hottest key. The accompanying prose explains the arrows, state changes, or table entries so the lesson remains understandable in a plain Markdown reader.
Editorial checks
Confirm that the numerical example agrees with its units and assumptions. Check that a faster path preserves the stated contract, or explicitly identify the changed guarantee. Keep hypothetical figures separate from product measurements. Explain both an appropriate use and a limitation of the case design. Check terminology against the glossary and links against the course index.