Section 8: A Trillion Names, No Committee - Deep Dive: Short-Code Generation

Executive Summary: This section designs the one piece of the write path that is genuinely hard: minting aZ3kP9q. We list what a code must guarantee, score six generation strategies against those guarantees, and pick a range-leased counter. Each Link API server leases blocks of 1,000,000 IDs from a one-row allocator, runs every ID through a keyed Feistel permutation over [0, 62^7), and base62-encodes it to a fixed seven characters. We show the numbers: a block lasts about 95 minutes per server at peak, a crash wastes at most two million IDs out of 3.52 trillion, and the space is 5.2 % full after five years. We also say plainly what the permutation does not buy.

The interviewer has taken the read path apart with you in Section 7. Now they turn to the write side: "Fine. Maya clicks 'Shorten.' Where does aZ3kP9q come from?"

A weak answer names a technique, usually "hash the URL". A strong one first says what a code must guarantee.

What a Code Must Guarantee

You write five properties on the board:

1. Unique, forever. Two links never share a code, and per Section 11's expiration rules a code is never reused.
2. Seven characters. Section 3 showed 62^6 ≈ 56.8 B codes run out in about 1.6 years at 100 M/day. 62^7 ≈ 3.52 T lasts about 96 years.
3. Non-sequential-looking. If aZ3kP9q were followed by aZ3kP9r, anyone could count our volume and walk through neighbouring links.
4. No coordination per request. At 3.5 K creates/s peak, a network round trip to a shared authority on every create is a bottleneck and a single point of failure.
5. Survives crashes. A server dying mid-block must never cause a code to be issued twice.

"Those are your criteria. Score the options against them."