Estimating Traffic, Storage and Cache for a Shortener
An interviewer gives you these assumptions for a URL shortener: 500 million new links per month, a 200:1 read/write ratio, links must be retained for 10 years, and each stored record averages 500 bytes.
- Compute average writes/s and reads/s, and a reasonable peak figure.
- Compute total storage after 10 years.
- Using the 80/20 rule, size a cache that holds the hottest 20% of URLs requested in one day. Is one Redis node enough?
1. Traffic
Seconds per month ≈ 30 × 86,400 ≈ 2.6 × 10⁶. Writes/s ≈ 5 × 10⁸ / 2.6 × 10⁶ ≈ ~190 writes/s. Reads/s ≈ 200 × 190 ≈ ~38,000 redirects/s average. Peak is typically 2–3× average, so plan for ~100,000 reads/s and ~500 writes/s. Writes remain trivial; reads are the scaling problem.
2. Storage
Links over 10 years = 5 × 10⁸ × 12 × 10 = 6 × 10¹⁰. Storage = 6 × 10¹⁰ × 500 B = 3 × 10¹³ B ≈ 30 TB. Add replication (×3) and index overhead → ~100 TB raw. That is firmly in "sharded store" territory; a single Postgres node is no longer a comfortable answer.
3. Cache
Reads per day = 38,000 × 86,400 ≈ 3.3 × 10⁹. Cache 20% of those (deduplicated by key it is fewer, but use the upper bound): 0.2 × 3.3 × 10⁹ × 500 B ≈ 3.3 × 10¹¹ B ≈ ~330 GB. That exceeds a single Redis node's comfortable memory, so use a Redis cluster of, say, 4–8 nodes with replicas, plus consider a CDN/edge KV in front to absorb the hottest keys globally. Note that many of the daily requests are for the same few keys, so the true unique working set is smaller — but you size for the upper bound and measure the hit ratio in production.
What the interviewer is checking: that you round aggressively, identify reads as the bottleneck, and translate the numbers into concrete infrastructure decisions (sharded store, Redis cluster, edge cache).
Share this question