Lesson 61 — System Design V: URL shortener

~20 minutes · Day 79 · system design

Tonight's interview design is a URL shortener: turn a long URL into something like /aB7x9Q, then redirect anyone who visits that code. It looks tiny, which is why interviewers like it. The product is simple enough to draw, but it exposes the real system-design habit: find the path that gets the most traffic, then protect it.

The invariant

A tiny write path (issue an ID, base62-encode it) feeding an enormous read path — design for the reads: one lookup per redirect, cache the hot links.

The script

The system-design script is always: requirements → estimate scale → API → data model → high-level boxes → deep-dive the bottleneck → failure modes. Apply it in that order; do not jump straight to boxes.

1. Requirements. Create a short code for a long URL. Redirect fast. Support expiry. Basic analytics can lag behind the user-facing redirect.
2. Estimate scale. Assume reads dominate writes. The System Design Primer example uses 10 million writes/month and 100 million reads/month, a 10:1 read-heavy system.
3. API. POST /links creates a code. GET /{code} returns an HTTP 302 redirect with the target in the Location header.
4. Data model. Store code, long_url, created_at, expires_at, and optional owner_id. Make code unique.
5. High-level boxes. Separate create traffic from redirect traffic. The redirect service checks cache first, database second.
6. Deep-dive the bottleneck. The hot path is GET /{code}: one lookup, then redirect. Analytics, abuse checks, and counters must not sit in front of the redirect.
7. Failure modes. If the cache is down, fall back to the database. If the database misses, return 404 or 410. If ID generation fails, stop writes rather than reusing codes.

POST /links
{ "long_url": "https://example.com/really/long/path" }

201 Created
{ "short_url": "https://sho.rt/aB7x9Q" }

GET /aB7x9Q
302 Found
Location: https://example.com/really/long/path

The write path can be boring: ask an ID generator for the next number, Base62-encode it, save the mapping, return the code. Boring is good. The read path is where the system earns its design.

The architecture diagram

The bottleneck deep-dive

The bottleneck is not making the short code. It is serving the same popular code again and again without melting the database. Three cache choices are worth saying out loud:

• Cache-aside + LRU. On redirect, read cache first. On miss, read database, then fill cache. Least-recently-used eviction is the clean default: simple, bounded, and good when recent links stay hot.
• Write-through warm cache. On create, write the database and cache together. This helps links that are shared immediately, but it adds write-path work and still needs cache-aside for cold misses.
• LFU or TinyLFU admission. Keep the frequently used links, not just the recently used ones. Better for celebrity links and viral posts; more moving parts to explain and operate.

For a first interview pass, choose cache-aside with bounded LRU, then mention that a production system may upgrade the admission policy if traffic is extremely skewed.

Numbers that matter

Practice — answer before you scroll past

Your move (tonight)

Redraw the architecture diagram from memory on paper. Then explain the design out loud in 5 minutes as if an interviewer is listening: requirements, scale, API, data model, boxes, bottleneck, failures. No LeetCode tonight.

For the encode step in your Notion tracker, write the invariant in your own words. The sentence should mention both sides: tiny write path, enormous read path.

Stuck or curious? Ask your teacher (the agent) — that's what it's for.