Skip to main content
CodePeetCodePeet
Data Systems at Scale

Checkpoint: The Database Landscape & Data Modeling

Fourteen Lessons, Eight Verdicts

This section handed you a map, an axis, a rubric, a method, and a book of contracts. The checkpoint asks the only question that matters: can you route a workload you've never seen?

Below are eight of them — session tokens under a 5-millisecond budget, 900 million chat messages a day, invoices that must never half-change, a search box, a Monday-morning dashboard with a body count, a GPS firehose, a tempting copy, and a friends-of-friends feature. Real rates, real budgets, real growth shapes, because that's the whole discipline: the numbers are the question.

First instinct, out loud, the way you'd say it in a design review: name the question's shape, check the invariants, be honest about the numbers — then commit. Six of eight passes. Every why tells you which lesson to revisit if it doesn't.

The section as a routing board — the checkpoint's own act, drawn. On the left, five workload chips with their real numbers: session tokens at 150,000 reads a second with a five-millisecond budget; chat messages at 900 million appends a day read as latest-fifty per room; B2B invoices with money invariants and new questions weekly; ranked dish search over two million descriptions; and analyst dashboards scanning two billion rows while checkout suffers. From each chip a bold arrow crosses to the family that answers it — key-value, wide-column, the relational default, a search sidecar, a columnar copy — with a sixth red unbounded GPS stream routed to a time-series store below. Beneath the board runs the section's arc as five big steps: the map of eight families, the row-versus-column axis underneath them, the six-question rubric, the access-pattern method, and the duplication contracts — ending in the section's one law: work is proportional to the question, and every layout is a bet on which question matters.

Route the Workloads

Route the workloads: for each scenario, commit to a store (or a modeling call) before reading the why — every explanation names the mechanism and the lesson it came from.

The Section, Compressed

If you keep nothing else, keep this:

  • Eight families, eight native questions — the value for a key · records kept correct · the whole aggregate · sorted-sparse width · relationships at depth · windows over time · relevance to words · similarity of meaning. Every store is a layout bet on one of them.
  • One axis under them all: rows for transactions, columns for analytics — same bytes, perpendicular questions, and whichever arrangement you pick, the other customer pays.
  • The decision is six questions, not two tribes: shape · invariants · tomorrow's queries · honest numbers · staleness · the pager. Default to Postgres; specialize on proof; re-run when answers change.
  • Model the queries, not the world: entities briefly, then the pattern table WITH numbers — in SQL the schema stays the world and the indexes model the queries; every index taxes every write.
  • When there are no joins, join at write time: accessed together → stored together; duplication is a contract — immutable copies free, bounded copies fine, mutable-and-hot never.

And the law that ran under all fourteen lessons: work is proportional to the question, and every layout — table, index, partition, collection — is a bet on which question matters.

Next, the course stops trusting the machinery: §2 opens the engine — what a B-tree actually does when it finds your row, why LSM-trees devour writes, and what the write-ahead log is really promising you.