Whiteboard Scale›URL Shortener›Cheat Sheet
Cheat Sheet

URL Shortener Cheat Sheet

Key concepts, trade-offs, and quick-reference notes for your interview prep.

QPS Estimation

#1
Write QPS=500M30×24×3600≈200/sec,Read QPS=200×100=20,000/sec\text{Write QPS} = \frac{500M}{30 \times 24 \times 3600} \approx 200/\text{sec}, \quad \text{Read QPS} = 200 \times 100 = 20{,}000/\text{sec}

💡 Always clarify the read:write ratio first. URL shorteners are extremely read-heavy (100:1 is standard).

Storage Estimation (5 years)

#2
500M×12×5×500B=15TB500M \times 12 \times 5 \times 500\text{B} = 15\text{TB}

💡 Each URL record is ~500 bytes (short code + original URL + metadata). 30 billion URLs over 5 years.

Base62 Key Space

#3
627≈3.5×1012 unique codes62^7 \approx 3.5 \times 10^{12} \text{ unique codes}

💡 62 = [a-zA-Z0-9]. 7 characters gives 3.5 trillion unique short codes, enough for decades.

⚠ Using 6 characters (56 billion) may seem enough but leaves no margin. Always use 7+.

Cache Hit Ratio

#4
Hit rate≥80%  ⟹  DB reads reduced by 5×\text{Hit rate} \geq 80\% \implies \text{DB reads reduced by } 5\times

💡 Popular URLs follow a Zipf distribution. 20% of URLs get 80% of traffic. Cache those aggressively.

Database Schema

#5
short_code (PK)∣original_url∣created_at∣expires_at∣user_id\texttt{short\_code (PK)} \mid \texttt{original\_url} \mid \texttt{created\_at} \mid \texttt{expires\_at} \mid \texttt{user\_id}

💡 short_code as primary key means every redirect is a single PK lookup - O(1) in any database.

API Endpoints

#6
POST /api/v1/shorten→{shortUrl},GET /:code→301/302,DELETE /api/v1/urls/:id\texttt{POST /api/v1/shorten} \to \{\texttt{shortUrl}\}, \quad \texttt{GET /:code} \to 301/302, \quad \texttt{DELETE /api/v1/urls/:id}

💡 Keep the read path (GET /:code) as fast as possible. It handles 100x more traffic than writes.

Redirect Flow

#7
Client→LB→App Server→Cache Check→DB Lookup→301/302\text{Client} \to \text{LB} \to \text{App Server} \to \text{Cache Check} \to \text{DB Lookup} \to 301/302

💡 Cache hit skips the DB entirely. Cache miss path: read from DB, write to cache, then redirect.

Scaling Thresholds

#8
Vertical→Horizontal at ∼10K QPS,Shard DB at ∼1TB\text{Vertical} \to \text{Horizontal at } {\sim}10K \text{ QPS}, \quad \text{Shard DB at } {\sim}1\text{TB}

💡 Start simple (single server + cache). Only add complexity (sharding, replication) when you hit limits.

301 vs 302 Redirect

#9
301=Permanent (browser caches)302=Temporary (trackable)301 = \text{Permanent (browser caches)} \quad 302 = \text{Temporary (trackable)}

💡 Use 301 for maximum performance (browser skips your server). Use 302 if you need click analytics.

⚠ Defaulting to 301 then realizing you lost all analytics. Decide upfront based on requirements.

Key Length Trade-off

#10
6 chars=56B,7 chars=3.5T,8 chars=218T6 \text{ chars} = 56B, \quad 7 \text{ chars} = 3.5T, \quad 8 \text{ chars} = 218T

💡 More characters = more capacity but longer URLs. 7 is the sweet spot for most systems.