Section 3: The Napkin That Draws the Architecture - Scale Estimation & Workload Analysis

Executive Summary: This section turns the interviewer's two numbers (100 M new links a day and a 100:1 read:write ratio) into every figure the design will be judged against: about 116 K redirects per second on average and 350 K at peak, 182.5 B links over five years, a 7-character base62 code space of 3.52 T, about 91 TB of logical storage, and a 100 GB hot set that fits in RAM. Then it does the step most candidates skip and lets the arithmetic decide things. A cache becomes mandatory, a single relational node is ruled out, a queue on create is ruled out, and 6-character codes fail on a clock you can read off the napkin.

The interviewer sets the marker down. "You've given me requirements. Now tell me how big this thing is." The memorized version says "lots of reads, use a cache" and moves on. The Staff version derives the numbers in front of the interviewer, rounds honestly, and then obeys them. Every number below gets written on the board in this order, because each one feeds the next.

Step 1: Traffic, from Days to Seconds

Start from the two numbers the interviewer gave in Section 1, plus the assumptions you commit to now: a 3× peak factor over the daily average and a 5-year capacity horizon (links don't expire unless the creator sets an expiry, so five years is how far ahead we plan, not when links die). A day has 86,400 seconds. Call it 10^5 when you sketch, but write the precise figure next to it.

Writes:  100 M links/day ÷ 86,400 s      ≈ 1,160/s   (~1.2 K/s average)
         × 3 peak factor                  ≈ 3.5 K/s   peak

Reads:   100 M × 100 (read:write)         = 10 B redirects/day
         10 B ÷ 86,400 s                  ≈ 116 K/s   average
         × 3 peak factor                  ≈ 350 K/s   peak

Say the asymmetry out loud: "Writes peak at 3.5 thousand per second. Reads peak at 350 thousand. These are two different systems sharing a database." That sentence is the whole of Section 6's read/write split.