Checkpoint: Scaling Reads

What This Section Handed You

Seven lessons ago, The Read-Scaling Playbook opened with one diagnostic question — is the database slow, or busy? — and a ladder. You've now climbed every rung with real numbers attached, and standing at the top, the whole section collapses into one law:

Read scaling has exactly two moves.

Move 1 — do less work per read. The index (one indexed box: 16,772 tps; two un-indexed machines: 51). The pooler (a connection is a ~13.9 MB process; 101 clients on 5 backends). The batch (501 round trips at 646 ms → one JOIN at 3.17 ms). These create no copy of anything — no staleness, no sync, no new failure mode. That is why they come first, every time.

Move 2 — answer from a copy. The replica (the database syncs it — and 272 bytes of lag vanished a user's write). The denormalized column (you sync it — and 1,008 increments became 75). The materialized view (the database syncs it on command — 589 while the truth said 100,589: old, never false). The cache (nobody syncs it — stale for a full TTL after the database healed). Every copy buys speed and hands you the same two questions: who syncs it, and what did you promise this read?

This checkpoint tests the skill that separates the section's graduates from its victims: reading the evidence before reaching for a lever.

The Scaling Reads section as a scoreboard, organized by its unifying law: read scaling has only two moves. Left column, in green, MOVE 1 — DO LESS WORK PER READ, no copy, no staleness, exhaust these first: THE INDEX (The Read-Scaling Playbook: one indexed box did 16,772 tps where two un-indexed machines managed 51 — the index beat doubling the hardware by ~327×); THE POOLER (Connection Pooling for Databases: a Postgres connection is a ~13.9 MB OS process, so an external pooler in transaction mode collapses 101 clients onto 5 backends); THE BATCH (Query Optimization in Practice: the N+1's 501 round trips at 646.5 ms became one JOIN at 3.17 ms — 136× — because the time was between the queries). Right column, in amber and red, MOVE 2 — ANSWER FROM A COPY, always buys a staleness contract, each copy labeled with who syncs it and its measured bill: THE REPLICA (synced by the database; 272 bytes behind was enough to vanish a user's own write); THE DENORMALIZED COLUMN (synced by YOU; 1,008 concurrent increments left the counter at 75); THE MATERIALIZED VIEW (synced by the database on command; the view said 589 while the truth said 100,589 — stale but never wrong); THE CACHE (synced by NOBODY; a correct delete plus a lagging-replica refill left the cache stale for a full TTL after the database healed — GitHub, March 2026). The footer carries the two questions every copy must answer — who syncs it, and what did you promise this read — and the checkpoint's charge: evidence first, lever second.

Triage: Three Slow Reads

You're on call. Three tickets, three different diseases with similar symptoms. Open the evidence (at least two tools per case), then commit to a lever. Fair warning from the section itself: in every case, the instinctive answer is one of the myths you've already been warned about — and the meters will bill you with the real numbers.

Three on-call tickets: read the evidence, then pick the lever — every wrong pick is a trap this section taught, with the measured number that kills it.

The Quiz: Eight Decisions

Eight scenarios spanning all seven lessons. Every wrong option is a trap this section explicitly corrected — if one tempts you, the explanation names the lesson to re-read. Six of eight passes.

Eight decisions across the seven lessons. Every wrong option is a myth this section corrected.

Where You Stand

If the triage felt like recognition rather than guessing — the bored-CPU-plus-ladder smell, the perfect-queries-pegged-box smell, the exactly-one-TTL smell — then §4 did its job: you don't scale reads by reflex anymore, you scale them by evidence, and every copy you create comes with a contract you wrote on purpose.

You may have noticed what this section carefully avoided: every lever here scaled reads. The writes still funnel into one leader, one table, one box — and no replica, cache, or index can absorb a write. When the write side becomes the wall, the answer is to split the data itself. Next: Partitioning vs Sharding — the section where the truth stops living in one place.