Walkthrough: a URL shortener

Why this question survives, and how the 45 minutes are spent

"Design a URL shortener" (TinyURL, bit.ly) is the most-asked warm-up in the industry and candidates dismiss it at their peril. It survives because the functional requirements fit in one sentence, which means 100% of your signal comes from how you reason, not from what you build. There is nowhere to hide behind domain complexity. Every senior-level muscle gets exercised: scoping, capacity estimation, an ID-generation choice with real collision math, a read-heavy caching story, and one planted trap that separates people who have run a system from people who have read about one.

Minute 0-5: the clarifying questions worth asking

Ask questions that change the design. "Should it be scalable?" is noise. Each of these has a wrong answer that would send you somewhere else entirely, and you should say why you're asking.

Then state the requirements back, split into functional and non-functional, and get agreement. Functional: create a short link from a long URL, optionally with a custom alias and an expiry; redirect a short link to its target; report click counts; delete or disable a link. Non-functional: redirects are the hot path and must be fast and highly available; creates can be slower and can tolerate brief unavailability; keys must not be enumerable; a link, once created, must never resolve to the wrong target — that last one is a correctness requirement, not a nicety, and it is what makes key uniqueness a security property rather than a hygiene issue.

Minute 5-10: back-of-envelope, line by line

Write the arithmetic on the board. Not the results — the arithmetic. Round aggressively and say that you're rounding. There are 86,400 seconds in a day; approximating that as 100,000 is standard and keeps the mental math clean, though below I'll use the real figure so the numbers reconcile.

Traffic.

• Writes: 10,000,000 ÷ 86,400 = 116 creates/sec. At 3× peak: ~350/sec.
• Reads: 10,000,000 × 100 = 1,000,000,000 redirects/day. 1,000,000,000 ÷ 86,400 = 11,574 redirects/sec. At 3× peak: ~35,000/sec.
• The two paths are three orders of magnitude apart. That single observation drives the entire rest of the design: separate services, separate scaling, and a cache that only the read path touches.

Storage over 5 years.

• Per row: 7 B short key + ~100 B average long URL + 8 B user id + 8 B created_at + 8 B expires_at + flags ≈ 132 B of payload. With row overhead, the primary index and one secondary index, budget 500 B per link.
• Rows: 10,000,000/day × 365 × 5 = 18.25 billion.
• Storage: 18.25 × 10⁹ × 500 B = 9.125 × 10¹² B = ~9.1 TB. With 3× replication, ~27 TB.
• Read that number back: 9 TB is small. It fits on three commodity volumes. Storage is not the hard part of this problem, and saying so out loud stops you over-engineering the next twenty minutes.

Bandwidth.

• Writes: 116/sec × ~500 B ≈ 58 KB/sec. Nothing.
• Reads: a redirect response is headers plus a Location, call it 500 B. 11,574/sec × 500 B ≈ 5.8 MB/sec ≈ 46 Mbps; 139 Mbps at peak. Also nothing — one server's NIC.
• Conclusion: this is a QPS and key-management problem, not a bandwidth or storage problem. Naming what the problem isn't is a senior move.

Cache sizing.

• Redirect traffic is strongly recency-skewed — most clicks land on links created in the last few days. Cache the ~10 most recent days of creations plus the evergreen tail: 10 × 10,000,000 = 100 million entries.
• Per entry: 7 B key + ~100 B URL + Redis object overhead ≈ 200 B. 100 × 10⁶ × 200 B = 20 GB — a three-node Redis cluster with room to spare.
• At a 95% hit rate the datastore sees 11,574 × 0.05 = 579 reads/sec (1,750/sec at peak). That is the whole point of the estimate: the read tier's job is to shrink 35,000/sec down to something a single replicated store answers without breaking a sweat.

Server count, since it always gets asked: a stateless handler that does one Redis GET and emits a 302 will do roughly 8-10k requests/sec on a modest instance. 35,000 ÷ 8,000 ≈ 5, so call it 12 instances across three availability zones — sized for redundancy and headroom, not for throughput.

Minute 10-16: the API surface and the redirect semantics

Then the question that looks trivial and isn't: 301 or 302? A 301 Moved Permanently lets the browser and every CDN cache the mapping, which is wonderful — your traffic collapses because repeat visitors never reach you again. That is also exactly the problem: you lose per-click analytics for repeat visitors, and you can no longer revoke the link. When a link turns out to point at a phishing page, a 301 you served yesterday is still redirecting victims from their browser cache and there is nothing you can do about it. So: 302 (or 307) with Cache-Control: private, no-store by default, because revocability and analytics are product requirements; offer 301 as a per-link option for high-volume customers who don't need either. Saying that tradeoff, rather than picking a number, is the answer.

Key generation: three strategies and the collision math

This is the technical core of the question. First, key length. Base62 (a-z A-Z 0-9) gives you 62 characters per position:

• 62⁶ = 56,800,235,584 ≈ 5.68 × 10¹⁰
• 62⁷ = 3,521,614,606,208 ≈ 3.52 × 10¹²

We need 18.25 × 10⁹ keys. Against 62⁶ that is 18.25 ÷ 56.8 = 32% of the keyspace — fine for a counter, disastrous for random generation, since by year five roughly one in three random draws would collide. Against 62⁷ it is 18.25 ÷ 3,521.6 = 0.52%. So: 7 characters if keys are random, 6 if they come from a counter. That difference is not cosmetic — a counter uses the keyspace densely, which is precisely what randomness gives up.

The counter approach deserves one more number, because it kills the obvious objection. Nobody increments a shared counter 116 times a second; you allocate ranges. Each app server takes a block of 1,000,000 ids and serves creates from local memory. At 10 M creates a day, the fleet consumes ten blocks per day — the counter service handles about ten requests in twenty-four hours, and can be a single row in Postgres behind a transaction. If a server crashes, its unused ids are lost: worst case a full fleet restart burns 12 × 1,000,000 = 12 million ids, which is 0.02% of 62⁶. Deliberately wasting 12 million ids to avoid a distributed counter is the correct engineering trade, and saying it that plainly is the signal.

Sizing the pre-generated pool, if you go that way: hold six months of buffer, 10 M/day × 180 = 1.8 × 10⁹ keys at 8 B each = 14.4 GB — a single table. Generate replacements at 116/sec, which is trivial. The one thing you must get right is the handout: two servers receiving the same key block means two links resolving to the same short code, which is a security bug, not a glitch. Hand out blocks inside a transaction that marks them taken, and accept losing a block when a server dies.

Data model, and the trap in the click counter

The read path does exactly one thing: point lookup by primary key. No joins, no ranges, no sorting. That is a pure key-value access pattern, which tells you the storage engine barely matters and the sharding key is obvious.

• links — short_key (PK, char(7)), long_url, user_id, created_at, expires_at, is_active. Sharded by hash(short_key): uniform distribution, and every redirect knows its shard from the URL alone with no lookup.
• links_by_user — a secondary index or GSI on user_id, for the low-volume "list my links" API. Do not let this exist on the redirect path.
• click events — a separate system entirely. Not a column. Not on this table. Not in this database.

The arithmetic: naive is 11,574 × 60 = 694,440 writes/min. Buffered is 12 instances × 6 flushes/min = 144 writes/min, a 4,800× reduction, and the redirect path now performs zero writes. If you want durable, attributable click events (geo, referrer, timestamp) rather than just counts, publish one event per redirect to Kafka and aggregate downstream — same principle, the redirect still never touches the primary store, and the analytics pipeline scales on its own budget.

Minute 16-30: the architecture

Walk the two paths out loud. Create: authenticate, validate and normalise the URL, check the idempotency key, take the next id from the in-memory block, write the row, populate the cache optimistically, return 201. Redirect: GET the key from Redis; on a hit emit a 302 immediately; on a miss read the shard, populate the cache with a jittered TTL, emit the 302; increment an in-process click counter and return. Nine times out of ten the entire request is one memory lookup in a co-located Redis and a response with no body.

Minute 30-45: the scaling path and the follow-ups

The follow-ups an interviewer will reach for, and the one-line answers:

• A link goes viral — one key gets 50,000 rps. That's a single hot Redis shard. Add a per-instance L1 cache with a 1-5 second TTL in front of Redis: 12 instances refreshing once a second is 12 reads/sec to Redis no matter how viral the link gets. The data is immutable, so a few seconds of staleness costs nothing.
• How do you expire 18 billion rows? Never a DELETE … WHERE expires_at < now() across the table. Partition by creation month so expiry is a DROP PARTITION, plus lazy deletion: if a read finds an expired row, return 410 and evict.
• Custom aliases racing. Same conditional insert as key generation, plus a reserved-word list (api, login, admin) so a user can't claim a path that shadows your own routes.
• Abuse and phishing. Scan the target on create against a reputation service; hold new links from untrusted accounts behind an interstitial; rate-limit creates per account and per IP. All of this depends on being able to revoke instantly — which is the argument for 302 you already made.
• What do you monitor? Cache hit rate (an early-warning signal for everything), p99 redirect latency, key-block depth per instance, create error rate, and the 404 rate on redirects, which spikes when a shard is misrouted.
• What breaks first? Be specific: the Redis cluster. At 95% hit rate the store sees 579 reads/sec; lose one of three cache nodes and the miss rate goes to roughly 0.33 + 0.67 × 0.05 = 0.365, sending 11,574 × 0.365 ≈ 4,200 reads/sec at the store — a 7× spike. Consistent hashing keeps a node loss from reshuffling the other two, and the store must be sized for the degraded number, not the healthy one.

What the interviewer was actually scoring

The rubric is never "did you produce the reference architecture." Almost everyone converges on roughly the same boxes. These are the axes that actually get written on the feedback form:

• Did you drive? Whether you scoped the problem yourself or waited to be handed requirements is usually decided in the first three minutes, and it is the single most common reason a strong engineer gets down-levelled here.
• Did a number change a decision? Estimation is not a ritual. The 9 TB figure is what justified not proposing an exotic distributed store; the 100:1 ratio is what justified splitting read and write services; the 20 GB cache figure is what made "95% hit rate" a claim rather than a hope. If your estimates didn't visibly steer anything, you performed the ritual without doing the work.
• Did you find the click counter? This is the planted trap. Spotting that per-click writes are 100× the create load — unprompted — is the strongest single signal available in this question.
• Did you commit? Comparing three key-generation strategies and then not choosing one reads as indecision, not rigour. Pick one, name what you're giving up, and say what would make you switch.
• Was your design proportionate? Reaching for Cassandra, Kafka and a stream processor in minute four for a system one Postgres box would serve is scored as a negative at senior level. Knowing the smallest thing that works, and knowing exactly which metric would force the next step, is the whole skill.
• Did you know your correctness boundaries? That the mapping is immutable (so replica lag and stale caches are harmless), that click counts are eventually consistent and may lose ten seconds (fine), but that key uniqueness must be enforced by a conditional write (not fine to hand-wave, because the failure is a link resolving to the wrong site).
• Did the follow-up land? "Now make it 100×" or "now it's multi-region" is a test of whether your design had joints. A design where the answer is "add more redirect instances and a regional cache" was built by someone who has scaled something; a design where the answer is "I'd rebuild it" was not.
• Level tell: a mid-level answer produces a design that works. A senior/staff answer additionally names the tradeoff it is accepting, quantifies the cost of that trade, states what it is deliberately not building, and identifies the metric that would change its mind.