Section 5: One Key to Rule the Read Path - Data Modeling & Storage Choice

Executive Summary: This section turns Section 4's contract into stored data. We list the access patterns before naming a database, discover that every hot path is a single-key lookup, and design four small tables around that fact: links, links_by_owner, id_allocator and idempotency_keys. We then run the storage deliberation (single Postgres, sharded Postgres, a distributed key-value store, Redis as primary) against the 91 TB that Section 3 projected. The key-value store wins, partitioned on short_code, with an honest flip trigger back to Postgres. The section closes on the property that makes the rest of the design easy: a link row is written once and almost never changes.

The interviewer points at the API you just wrote: "Fine. What's behind it? Tables, keys, which database." The reflex answer is "Postgres and an auto-increment ID". Start instead with every way the system touches stored data, and how often.

Access Patterns First

Read the "Shape" column. Every hot pattern is "give me the row for this one key". There are no joins, no aggregates and no cross-link queries. The only range query, listing an owner's links, is rare and allowed to lag a little.

Key Insight: Once the access patterns are written down, the storage choice mostly follows. A system whose hot path is a single-key lookup at hundreds of thousands per second, over a dataset too big for one machine, wants a database built to do exactly that, and not much else.