The Problem Everyone Has Memorized: Designing TinyURL

maang.io System Design Series

"Design TinyURL" may be the most-rehearsed prompt in system design. Candidates walk in with a blog-post answer already loaded: hash the URL, store it in a database, add a cache. Interviewers at large tech companies keep asking it anyway, because the memorized answer falls apart at the first follow-up. Why seven characters and not six? What does your hash do when two URLs collide? Why a 302 and not a 301? What happens when one link takes 16,700 clicks a second?

This module answers each of those questions with arithmetic rather than recital.

The Trap Built Into a Familiar Problem

A familiar prompt fails candidates in two predictable ways:

• The Recital: the candidate repeats a design they've read, without deriving a single number. When the interviewer changes one assumption, the design has no reasoning underneath to adapt.
• The Citadel: the candidate, afraid of looking junior on an "easy" problem, adds Kafka on the write path, a consensus protocol for ID generation, and a microservice per verb, all for a write path that peaks at about 3,500 requests per second.

The passing answer sees that one name covers two very different systems: a thin write path that mints a code about 1,200 times a second, and a huge read path that redirects about 116,000 clicks a second. Each half gets engineered in proportion to its load.