Exam Prep & Other Resources

Start with CS145 exam practice. For weekly requirements and deadlines, see the course schedule. Case studies and interview resources follow below.

CS145 Exam Prep

Rough format: approximately 30 MCQs plus 2–3 FRQs.

FRQ practice: One FRQ will ask you to write SQL using, for example, CTEs, window functions, and subqueries. Review Writing SQL. The projects, especially Project 1, are your best practice for this.

Week 8: practice exams will be released.

Allowed materials: You may bring two 8.5" × 11" sheets of paper (standard letter size), with any material on both sides: two double-sided sheets total. We will also provide the standard CS145 equations sheet covered in lecture.

Other Resources

Case Studies for Modern Data Systems 27 pages

How real systems actually work.

Most read
The rest, in course order
M0
Pandas: small analytics
A laptop holds 16 GB of RAM. Spotify holds billions of listens. Everything after this page is that gap.
Open →
M0
Claude & OpenAI: agent memory
The context window is short-term memory, wiped the moment the session ends. Anything that must outlast it lives in a database.
Open →
M0
UberEats: a big service
A burrito order has three sides, and all three have to agree the instant it is placed. That is the job a transaction does.
Open →
M2
Uber and Maps: geo-hashing
One grid key instead of two coordinates, so “drivers within 2 km” is a few cell lookups instead of distance math over millions of rows.
Open →
M2
Chrome Safe Browsing: Bloom filters
Chrome checks every URL you open against millions of bad ones, without shipping the list or asking a server.
Open →
M3
BigQuery scaling
“Scan a petabyte” becomes “scan three columns on a thousand workers.” Storage and compute bought separately.
Open →
M3B
Spotify search
100 million tracks, and a search reads one short list per word instead of scanning any of them.
Open →
M3B
Spotify activity
A billion plays a day. Writes never overwrite anything; they append, and the sorting happens later.
Open →
M3B
Spotify Wrapped
December 1 is the year’s biggest read spike, and it costs one row per user, because November already did the work.
Open →
M3B
The $550k query disaster
One missing index, one query, a hundred times a day. $550,000 a year.
Open →
M4
ACID at Stripe
One Stripe charge is four writes across four tables. All four land or none do, and there is no third outcome.
Open →
M5
GFS: the internet on dying disks
Build storage out of drives you expect to fail, and buy reliability with replication instead of hardware.
Open →
M6
OpenClaw’s memory
Files are enough for one agent. The moment several share a memory you need a database, and locking comes back with it.
Open →
M6
DB design for a startup
Most apps never outgrow one machine. Start on one Postgres, add read replicas, and reach for sharding far later than you think.
Open →
M6
SQL beyond tables
One engine stores documents, arrays, geo points and vectors, all through the same SELECT. Most “we need NoSQL” arguments end here.
Open →
M6
DB design at big-tech scale
The stack splits in three: OLTP for writes users see, OLAP for analytics over billions of rows, and a pipeline moving data between them.
Open →
M6
Data quality & observability
A fare field vanished from one in ten Uber sessions. Every nightly job ran green. Someone noticed forty-five days later.
Open →
M6
SQL vs NoSQL
One Postgres row now holds a rigid ID, a JSON blob and a vector. Most of the old reasons to leave SQL have expired.
Open →
M6
Key-value stores
Song lyrics do not want to be columns. One key, one blob, one hop, and no joins ever.
Open →
M6
Claude’s KV cache
An agent resends the same long prefix every turn. Cache it and the cost per turn collapses.
Open →
M6
Privacy
Deleting names does not anonymise anything. One sensitive place on a known day is enough to put the name back.
Open →
Data / SQL Interview Prep ≈ 3–5 hrs

For SQL screens and analytics-engineer interviews. Start with the patterns interviewers actually test (Round 1 = single pattern, Round 2 = composition), then drill on the playground, then read how Postgres scales in the wild for the inevitable "how would you scale this?" follow-up.

Systems Design Interview Prep ≈ 6–10 hrs

For data-infra, backend, and platform-engineering interviews. Start with the IO cost model (the substrate every systems answer rests on), then index selection, then a real-world transaction disaster, then distributed primitives. Each step is a concrete pattern you can name in an interview.

Going Deeper — Reading List post-class

For when class is over and you want to keep reading. Everything here is outside the course: the papers the field was built on, and engineering write-ups from teams running these systems now.