A worked mini-walkthrough — applying the framework

The prompt

“Design a service that shortens long URLs and redirects visitors to the original.” (We’ll go deep on this in Chapter 4 — here we just practice the motion.)

Walk it through the five steps from this chapter. Notice how each step feeds the next; nothing is decided by taste alone.

Step 1 — Clarify and scope (functional)

Ask, don’t assume. A good exchange:

• Custom aliases, or system-generated only? → system-generated for now.
• Do links expire? → assume they live forever.
• Do we need analytics (click counts)? → nice-to-have, out of scope for v1.

In scope: create a short link; redirect a short link to its target. Out of scope: custom aliases, expiry, analytics. State this back to the interviewer.

Step 2 — Non-functional requirements

• Read-heavy: redirects vastly outnumber creations (~100:1).
• Low latency: a redirect should feel instant (tens of ms).
• High availability: a dead shortener breaks every link that uses it.
• Consistency: a freshly created link should work right away, but it’s fine if global propagation lags by a moment → eventual consistency is acceptable.

Step 3 — Estimate (just enough)

• 100M creates/day → ~1k writes/sec average, a few k at peak.
• 100:1 reads → ~100k redirects/sec. This single number says: serve redirects from a cache, never hit the DB on the hot path.
• ~500 B/record → tens of TB over a few years → partition the store.

Step 4 — High-level design

client → load balancer → app servers ──> cache (hot short→long lookups)
                                  │            │ miss
                                  │            ▼
                                  └────────> key-value store (sharded)
                          write path: generate id → store mapping

• Write: generate a unique short id, store shortId → longUrl in a partitioned key-value store.
• Read: look up shortId in the cache; on a miss, read the store, populate the cache, return a 301/302 redirect.

Step 5 — Drill into the interesting part

The one genuinely interesting design question here is how to generate the short id:

• Hash the URL (e.g. base62 of a hash) — simple, but collisions need handling and identical URLs collapse to one link.
• A counter encoded in base62 — guarantees uniqueness and short codes, but a single counter is a bottleneck → hand out ranges of ids to each server, or use a dedicated id generator.

State the trade-off, pick one (say, ranged counters for guaranteed-unique, short codes), and move on.

Step 6 — Stress it

• Hot key (a viral link): the cache absorbs it; add read replicas if needed.
• A node dies: replication + a load balancer health check route around it.
• Cache miss storm: the store is partitioned, so misses spread across shards.

The takeaway

You didn’t need to know anything exotic — you needed to run the steps in order and let each number and requirement justify the next move. That motion is identical whether the prompt is a URL shortener or a global video platform. The rest of this course gives you the building blocks (Chapter 2), the trade-offs (Chapter 3), and the practice (Chapter 4) to run it on anything.