31.4 What do we store?

links code (primary key) "aB3x9Qz" long_url "https://example.com/some/very/long/page" created_at 2026-10-05 10:00:00 creator_ip (optional) for abuse checks click_counts (in the analytics store, filled asynchronously) code, hour, clicks

The hot question is always "given this code, what's the long URL?". That's an exact-key lookup, so store it the way you'll ask for it (Chapter 1): the code is the primary key. A relational database works at this size and gives us the uniqueness check for free; a key-value store would also work. Click counts live separately so they never slow the redirect table.

Interviewer pushback:

• "SQL or NoSQL?" → Either works for one exact-key table. I'd start with a relational database because 3 TB and 40 writes a second fit one primary plus replicas, and the primary key enforces unique codes. If we later needed to shard, a key-value store that shards by key is a natural move (Chapter 8, Chapter 15).
• "Why not store click counts in the links table?" → Every redirect would then be a write to the hottest table. At 12,000 a second at peak, that turns our read path into a write path. Counting goes on a separate, asynchronous path (31.9).

Memory code: "Code is the key, counts live next door."

---