The Smallest System, the Sharpest Constraints

In one line: every previous chapter in this module was about moving bytes at scale. This one moves almost nothing, and the hard part is a counting argument.

The service

A URL shortening service creates a short alias, or short link, for a long URL. When a user clicks the short link, they are redirected to the original, longer address.

The scale is tiny, and that is what makes the chapter interesting

Put this chapter's numbers beside the ones you have just spent eight chapters on:

Six terabytes. Thirty megabits per second. That is a single commodity server with room to spare, and Lesson 3 will show the honest server count is a fraction of one machine.

So why is this one of the most-asked system design questions?

Because the difficulty moved from engineering to arithmetic. There is no fan-out problem, no media pipeline, no ranking model. What there is instead:

A counting problem. How many characters must a short URL be, given how many you need to store? Lesson 9 derives it.

A conflict between requirements that cannot all be satisfied. Short, unguessable, and twelve billion of them — pick two. Lesson 10 works it out, and the chapter never notices it.

An encoding problem. Turning a 64-bit integer into something a human can read aloud, which is Lessons 7 and 8.

When a system is small, the interesting constraints are informational rather than physical. That is a genuinely different kind of design problem, and it is why this question survives as an interview staple.

Roughly a thousand clicks per URL created. That single ratio is why the interesting engineering is all on redirect latency and none of it on write throughput — about one new row per second is nothing for any database.

What the chapter gets right

The arithmetic here is the most rigorous in the module

Worth saying up front, because the previous chapters have trained you to check.

This chapter's base-58 conversions are exactly correct in both directions. It encodes 2468135791013 to 27qMi57J, showing every remainder, then decodes it back showing every power of 58 — and both round-trip precisely. The digit-count derivation (64 / log₂58 = 10.9, so 11 characters) is right. The sequencer lifetime is right to two decimal places.

That precision is unusual and it makes the chapter worth reading closely. When a source is careful with the arithmetic it shows, its errors are more likely to be in the arithmetic it does not show — which is exactly where Lesson 3 and Lesson 10 find them.

And one error of a kind you have now seen five times

Lesson 3 covers it in full, but the shape will be familiar.

The chapter computes its read rate carefully: 7,610 redirections per second. Then the server section asserts "a peak load of 100 million requests per second" — the daily-active-user count reused as a rate — and derives 1,562 servers.

Computed:  7,610 QPS
Asserted:  100,000,000 QPS
Factor:    13,141x

The largest such gap in the module. The coherent answer is 0.12 servers.

By now the pattern should be automatic: when a document computes a rate and then substitutes a different one, recompute before using either.

The three things to hold onto

The single most important design decision, stated early

The chapter separates two concerns that most naive answers conflate:

UNIQUENESS  -> a sequencer generates a unique 64-bit integer
READABILITY -> a base-58 encoder turns that integer into a string

That separation is the whole design. Uniqueness is guaranteed by the number, not by the string — because base-58 encoding is a bijection, distinct integers always produce distinct strings. So there is no collision detection, no retry loop, no hash comparison.

Compare the common alternative: hash the long URL, take the first N characters, and check for collisions. That approach requires a database read on every write to detect collisions, and the collision rate rises as the table fills.

Deriving uniqueness from a counter rather than a hash removes an entire class of problem — and it is why the sequencer, not the encoder, is the load-bearing component.

Next: the requirements, including one that will turn out to be unsatisfiable.