Learning objectives
By the end you can:
- Explain the memory hierarchy (registers → L1/L2/L3 cache → RAM → SSD → spinning disk → network) as a ladder of distance, and use rough latency ratios to predict, before measuring, which of two designs will be faster.
- Explain virtual memory and paging well enough to simulate page replacement by hand, implement the FIFO policy in code, and correctly predict and explain Belady's anomaly (more memory making performance worse, not better).
- Implement an LRU (least-recently-used) cache, contrast its eviction logic with FIFO's, and reason about when a cache's assumption about access patterns matches, or mismatches: reality (cache pollution, thrashing).
- Contrast row-oriented and column-oriented physical storage layouts, compute the bytes an analytic query must scan under each, and explain why Parquet and similar formats exist and what they cost you in return (write cost, mutation cost).
- Explain and implement run-length encoding as a concrete instance of "compression only pays off on the right kind of data," and predict when compression helps versus when it actively hurts.
- Explain why databases use B-trees, not binary trees or linear scans, for on-disk indexes; compute an index's height from its key count and fan-out; and reason about when an index helps a query and when it does not (selectivity).
- Implement a small deterministic hash index and explain, from first principles, why Python's built-in
hash()is the wrong tool for a persisted, cross-run index. - Sketch the shape of a small analyst data warehouse: the OLTP-vs-OLAP distinction, a star schema of fact and dimension tables, and where a batch/ETL pipeline sits between the two, and write the aggregation query that sits at the center of it.
- (Productivity objective: R10 duality.) Use an AI coding assistant to accelerate writing systems-adjacent code (a cache, a query, a storage-layout experiment) after you can already explain the mechanism yourself by hand, and catch the specific ways AI-generated systems code goes subtly wrong (off-by-one eviction order, a plausible-looking index that doesn't match the query, a schema that silently drops a constraint).
The duality, stated once (R10). As in every module in this program, this node carries two objectives at once. The understanding objective (items 1–8) is what the mastery gate rewards; you earn the pass by explaining the mechanism and by clearing the code pack's hidden tests, not by having an assistant write code you cannot defend. The productivity objective (item 9) is the payoff you keep afterward: knowing how to point a copilot at systems work without being quietly misled by it. A tool can never buy you a pass on the gate.
Prerequisites & connections
Builds on. CS2.03 (Databases & SQL for Analysts) is the direct foundation, you already know how to ask a database for rows via SELECT/joins/aggregation, and you already have the vocabulary for indexing and ACID as user-facing guarantees. This module goes one level down: not "what do I type" but "what actually happens to bytes on a disk and in RAM when I hit enter." CS1.04 (Algorithmic Thinking, Recursion & Big-O) supplies the complexity vocabulary this module leans on constantly (a B-tree's height is a log; a full scan is linear; a hash lookup is amortized constant), if O(log n) versus O(n) doesn't yet feel visceral, revisit CS1.04 before this node's Practice set. CS1.02's discipline around mutability and clean function design shows up directly in the code pack (every exercise is a small, pure, testable function). You do not need calculus, statistics, or prior machine-learning exposure for this node, it is a pure systems module.
Feeds forward. CS2.05 (APIs, HTTP, JSON & Web Scraping) inherits this module's caching vocabulary directly, a rate-limited API and a buffer pool are solving structurally the same "expensive round-trip, cache what you can" problem. CS2.06 (Software Engineering) will ask you to write tests and reason about performance regressions for code whose mechanism you now understand rather than merely observe. In the DA branch, pandas's entire performance story, why vectorized column operations crush row-wise Python loops, why a wide DataFrame with one huge text column behaves differently from a narrow numeric one, is a direct, unannounced consequence of the row-vs-column reasoning built here; DA1.02/DA1.03 will assume it. In the QD branch, QD1.01's point-in-time, survivorship-controlled research panels are exactly the kind of data-intensive storage-and-retrieval problem this module is training you to reason about before you build one at scale. None of this module touches statistics, probability, or machine-learning theory, that remains QM's (G1) and DA's (this branch's DA1.05/DA2.x) territory; this node's business is purely mechanical: memory, storage, and the shape of a warehouse.