study

Books you read, turned into labs you run. Each exercise makes you predict a specific behavior, run the real thing, and check your prediction against a real transcript — the gap is where the mental model gets built.

Designing Data-Intensive Applications

Kleppmann & Riccomini, 2nd ed. (2025).

Chapter 2 · Defining Nonfunctional Requirements

• Tail-Latency Amplification — a backend call slow just 1% of the time, fanned out to 100 parallel calls, makes 63% of end-user requests slow. Predict "still ~99% fast"; measure ~37%.
• The Mean Hides the Tail — for right-skewed latency, 69% of requests are faster than "average," yet p99 is 6× the mean. The average overstates the typical request and understates the tail at once.
• Averaging Percentiles Is a Lie — average ten servers' p99s and you land 21% below the true pooled p99. Predict "close enough"; measure the gap.

Chapter 3 · Data Models and Query Languages

• ADD COLUMN Is Instant, Until It Isn't — adding a NOT NULL column with a default to a 10M-row Postgres table takes 0.8 ms, not the full rewrite everyone predicts — but a volatile default rewrites it in ~8 s.
• Reachability Needs Recursion — "is Boise in North America?" A two-level join silently answers no (it's 4 hops deep); WITH RECURSIVE gets it right at any depth. A fixed join count can't express transitive reachability.
• One Company, Two Names — a denormalized rename touches 666,666 rows vs 1; interrupt it and one company splits into two names — an inconsistency the normalized schema can't represent.
• The Document Wins the Whole Read and Loses the Field — a JSONB document reads ~20× fewer pages than the join for a whole profile, but ~12× more for a single field. Locality cuts both ways.
• You Can Index Inside a Document — a nested-field filter scans 2M rows (~98 ms); a GIN index makes it ~27× faster — with the catch that it serves @>, not ->> equality.
• The Ratings Matrix That's 99% Empty — a 1%-full ratings matrix is 200 MB dense vs 4 MB sparse (50×), following 1/(2×density). Netflix-scale dense is 34 GB.

Chapter 4 · Storage and Retrieval

• The Column Store Reads Only What It Needs — a 2-column query over a 30-column table makes a row store read 100% of the data and a column store 0.6% — 165× less — from layout alone.
• Sorting Rows Changes How Big They Are — a column store is 5.5× smaller than the row store; reordering the same rows shrinks it another 1.4×, one column collapsing 30×. Sort order is a compression lever.
• Ten Bits per Key Buys a 1% Miss Rate — a Bloom filter needs ~10 bits (not bytes) per key for a 0.8% false-positive rate, matching the formula — and its size is independent of key length.
• The Same Rows Cost 4× More in Random Order — load 10M rows into a B-tree in random key order and it's 4× slower with a 31% bigger index (69% vs 90% leaf fill). Why LSM writes sequentially.
• The Covering Index That Still Reads the Heap — a covering index keeps reading 1,637 heap blocks until one VACUUM sets the visibility map; then heap fetches drop to zero.
• LIKE Reads Every Row; an Inverted Index Reads Five Buffers — finding a word with ILIKE '%…%' scans 5M rows (~1.25 s); a tsvector+GIN index does it in ~19 ms, the probe touching 5 buffers — ~65× faster.
• Storing 230 MB Wrote 2 GB to Disk — an LSM (RocksDB) writes 2,091 MB to durably store 230 MB — a 9× write amplification, ~7× of it compaction — while the database ends up just 235 MB.

Source: github.com/atharh/study · each exercise's .md is the source of truth; the .html is its rendered companion.