Section 5: Where a Post Actually Lives - Data Modeling
Executive Summary: Maya's post lives in three stores at once. Postgres holds the metadata and one pointer. A KV store holds the draft she is still typing into. Object storage holds every revision she has checkpointed or published, keyed by a SHA-256 of the content. This section derives those homes from the access patterns, then keys, sizes and defends them. The idea everything later depends on: editing never touches what readers see. Publishing flips a pointer.
The interviewer taps the endpoint list from Section 4: "Okay. What sits behind these on disk?" Don't start with tables. Start with the questions the system asks its data, and how often.
Access Patterns First
| Access pattern | Rate (peak) | Key it needs | Home |
|---|---|---|---|
| Read a post by ID (origin render on a CDN miss) | ≤ 175/s | public post ID → live revision | Postgres primary (pointer) + object storage |
| List a publication's posts, newest first | low | (publication_id, first_published_at DESC) |
Postgres |
| Load and save the draft | ~1,560 saves/s | post_id, compare-and-set on draft_version |
KV store |
| List a post's revisions | low | post_id, by time |
Postgres |
| A reader's Following feed | ~1,750 loads/s | user_id, by published_at DESC |
KV inbox |
| Who follows publication X (fan-out) | ~230 inserts/s avg | publication_id |
KV |
| Does Daniel follow X, how many claps did he give | ~2,100/s (/me) |
user_id (+ post_id) |
KV |
Two rows stand out: autosave is the busiest write and a single-key overwrite, and reads cost origin at most 175 renders a second because the CDN absorbs the rest.
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson