URL Shortener — bit.ly / TinyURL

Design a URL shortener. 100M URLs/day, 10:1 read:write, < 100ms p99 redirect latency, analytics on click counts.

Time budget: 30 min whiteboard. Draw architecture, estimate numbers, discuss tradeoffs.

Hint 1

Short-code generation: base62 over a 64-bit counter = ~11 chars; or hash + collision check.

Hint 2

Write path: Postgres sharded by counter-range; read path: Redis cache + DB fallback.

Hint 3

Analytics is async: click event → Kafka → batch aggregate into clickhouse/BigQuery.

• +1 Short-code: base62 of counter (~7 chars for 62^7 = 3.5T URLs) OR hash + collision check
• +2 Counter-based via distributed sequence generator (Snowflake / Ticket servers); no central bottleneck
• +2 Read path: Redis cache (hot URLs) → Postgres (warm) — sharded by short_code hash
• +1 Click analytics async: emit event → Kafka → aggregator → ClickHouse for query
• +1 BoE: 100M/day → 1K writes/sec, 10K reads/sec; ~500 GB/yr URL storage
• +1 Custom short-codes: reserve namespace; collision detection on pick
• +1 Expiry + analytics retention: cold URL cleanup; tiered storage for old data
• +1 Abuse prevention: rate-limit per IP on creation; URL reputation check (Safe Browsing)

Self-score: tally the points you would have mentioned unprompted. 7+ is interview-ready on this problem.

• UUID as short-code (too long — defeats the purpose)
• Sequential INT from one DB counter (becomes bottleneck)
• Synchronous click-count increment in redirect path
• No cache — every redirect hits DB
• No abuse prevention (becomes phishing relay)