Design a URL shortener

Interview 1: Design a URL shortener

We run the lesson 9-2 script, start to finish.

Step 1, requirements. Functional: given a long URL, return a short one, and redirect anyone who visits it. Non-functional: redirects must be fast (they sit in front of every click) and highly available. Out of scope after asking: custom aliases, analytics dashboards.

Step 2, estimation. Assume 100 million new URLs per month and a 100:1 read-to-write ratio.

• Writes: 10⁸ / month ≈ 40 per second average. Tiny
• Reads: 4,000 per second average, maybe 20,000 at peak. Read-heavy, exactly what unit 3 caches love
• Storage: 10⁸ URLs × 500 bytes ≈ 50 GB per year. One database easily holds a decade

Conclusion, said out loud: this is a small-write, huge-read system. One SQL leader with replicas plus an aggressive cache. No sharding needed for years.

Step 3, API and data model

Two endpoints:

POST /shorten   body: {"url": "https://long..."}   returns {"code": "xK9fQ2p"}
GET  /<code>    responds 301 redirect to the long URL

One table: links(code PRIMARY KEY, long_url, created_at). The interesting question is the code. Use base62: the 62 characters a-z, A-Z, 0-9. Each character multiplies the keyspace by 62, so length 7 gives 62⁷ possible codes.

To generate codes without collisions, keep a global counter (or ranges of IDs handed to each server) and convert each number to base62, the same way binary converts numbers to base 2. Every ID maps to a unique short string, no collision checking needed.

Steps 4 and 5, architecture and deep dive

The redirect path is the unit 1 anchor grown with everything you learned:

1. GET /xK9fQ2p hits the load balancer (unit 2), then any stateless app server (lesson 2-3)
2. The server checks Redis with cache-aside (lesson 3-2). Popular links are nearly always hits, and links never change, so staleness is a non-issue: cache forever with a long TTL
3. On a miss, read the database by primary key (indexed, lesson 4-1), from a read replica (lesson 4-3), and fill the cache
4. Respond with a 301 redirect, total time a few milliseconds

Writes take the boring path to the leader. Deep-dive favorite: a viral link is a hot key (lesson 5-2), and the cache is already the answer.

Notice what we did not use: no shards, no queues, no microservices. Matching the machinery to the numbers is the win.