Design a URL shortener handling 100 million new links per month and 10 billion redirects. Where is the real difficulty?

What the interviewer is testing

The classic warm-up. What is being assessed is not whether you can shorten a URL — it is whether you do capacity arithmetic before designing, and whether you notice that reads dominate writes by 100:1.

Do the numbers first

• Writes: 100M/month ≈ 40 per second average, perhaps 200 at peak.
• Reads: 10B/month ≈ 4,000 per second average, perhaps 20,000 at peak.
• Storage: 100M rows/month × ~500 bytes ≈ 50 GB/month, 600 GB/year.
• Key space: base62 at 7 characters gives 3.5 trillion — decades of headroom.

The write path is trivially small. This is a read system, and the design should say so.

The design

Key generation. Three options, and the choice matters:

• Hash the URL and truncate — collisions must be detected and handled, and identical URLs collapse to one key, which breaks per-link analytics.
• Random and check — simple, needs a uniqueness check per attempt, fine at 200 writes per second.
• Counter with base62 encoding — no collisions by construction, but sequential keys are enumerable, which leaks link volume and lets anyone walk the corpus. Pre-allocated ranges per writer plus an obfuscating permutation fixes both.

Counter with per-instance ranges is the answer I would give, with the enumeration caveat stated, because it removes the collision path entirely.

Read path. Cache-aside in front of a key-value store. Access is heavily power-law — a small fraction of links take most of the traffic — so a modest cache serves 95%+ of reads. Redirects are also an excellent CDN candidate: a 301 with a long TTL can be served entirely at the edge for links that never change.

Storage. A key-value store with the short code as the partition key. No joins, no scans, no relational features needed. This is the workload key-value stores are for.

Redirect semantics. 301 is cacheable forever and therefore fast and cheap, but you lose all subsequent analytics and can never change the target. 302 keeps both, at the cost of every redirect reaching your infrastructure. If analytics is a product feature, 302 — and say why.

Where the real difficulty is

Not the shortening. It is:

• Analytics at 4,000 events per second. Writing a row per redirect is a much larger write workload than the links themselves. Buffer, batch, and aggregate asynchronously; do not write synchronously in the redirect path.
• Abuse. URL shorteners are a phishing and malware delivery mechanism. You need a reputation check on creation, a takedown path, and rate limits per account. Interviewers notice when this is missing.
• Custom aliases, which reintroduce uniqueness contention and a namespace to police.
• Expiry and deletion, which interact badly with a 301 already cached in a billion browsers.

What a strong answer adds

Noticing that a cached 301 is effectively permanent, and choosing the redirect status deliberately as a product decision rather than defaulting.