The Runtime Theory

URL Shortener Write Path: From Long URL to Short Code

Follow a URL through the write path: ID generation, base62 encoding into a short code, mapping storage, and the cache that makes redirects cheap.

The Runtime Theory Team08 stages

trace / request.md

LONG URL ISSUBMITTEDINPUT ISNORMALIZEDUNIQUE IDIS MINTEDID BECOMESA SHORT CODEROW IS PERSISTEDMAPPING WARMSTHE CACHECODE RETURNSTO THE CLIENTREADS PAYOFF THE WRITE

readyThe client POSTs a long URL. The write path's job is to mint a unique short code and store the mapping, so that every redirect — the read path — can be served cheaply.

The URL shortener write path exists to make the read path trivial. This diagram follows the write: validate the URL, mint an ID, encode it to base62, store the mapping, warm the cache, return the code. The interesting engineering sits in two decisions. The first is the code itself: base62 encoding turns a numeric ID into a shorter, shareable string, and because the encoding is a pure function of the ID, collisions are impossible by construction. The second is the ID source: a global counter is simple but a coordination point, while snowflake-style IDs mint locally and keep codes unguessable.

The ordering matters for durability and latency. The database write must land before the code is handed out — otherwise a redirect could 404 a URL that was just created. The cache write rides along to make the first redirect as cheap as the millionth. Every stage after the ID minting is deterministic plumbing; the ID strategy is the decision that shapes everything downstream.