Walkthrough: designing a URL shortener

A URL shortener is a common first system design problem specifically because it's small enough to fully reason about in 30-45 minutes, but touches every concept from the previous lessons. Here's one reasonable path through it.

1. Clarify the problem

Before designing anything: how many URLs get created per day, what's the read:write ratio (shortened links are read far more often than they're created — often by orders of magnitude), do short codes need to be unpredictable, and is there a custom-alias feature. These answers change the design meaningfully, so ask before designing.

2. The core operation

Two endpoints: create a short code for a long URL, and redirect a short code to its long URL. The redirect path is the hot path — it needs to be fast and needs to handle far more traffic than creation.

3. Generating the short code

A common approach: a counter (or a hash of the URL) converted to a short base-62 string (a-z, A-Z, 0-9). The tradeoff to name out loud: a counter is simple and collision-free but predictable/guessable; a hash needs a collision-handling strategy but isn't sequential.

4. Where the tradeoffs from earlier lessons show up

• Caching — the redirect path is read-heavy, so caching popular short codes (in memory, close to users) directly addresses the read:write ratio from step 1.
• Consistency — once a short code is created, it basically never changes, so this system can lean toward availability without much consistency risk — a good example of a design where that tradeoff is easy, not painful.
• Horizontal scaling — the redirect service can be stateless and scale out behind a load balancer; the harder scaling question is usually the database holding the code-to-URL mapping, which is where a discussion of sharding by short code would naturally go if the interviewer pushes further.

The point of this exercise

Notice that every decision above ties back to an answer from step 1 or a concept from the earlier lessons — that's exactly the muscle system design interviews are testing: not knowing the "right" URL shortener design, but building one deliberately from stated requirements.