Solution PathTarget: 5 min
Convert monthly traffic to per-second QPS, then apply the read:write ratio. The 100:1 ratio reveals this is an extremely read-heavy system that must be optimized for fast redirects.
We are given 500 million new short URLs created per month, with a read-to-write ratio of 100:1. We need to estimate write QPS and read QPS.
Given: 500M new URLs/month, read:write ratio = 100:1
Convert monthly writes to per-second: divide 500 million by the number of seconds in a month (30 days * 24 hours * 3600 seconds = 2,592,000 seconds).
Write QPS = 500,000,000 / 2,592,000 = ~200 writes/sec
03Calculate Read QPSKEY INSIGHT
3/4The read-to-write ratio of 100:1 means for every URL created, it gets redirected 100 times. Multiply write QPS by 100 to get read QPS. This tells us the system is extremely read-heavy.
Read QPS = 200 * 100 = 20,000 reads/sec
At 20K reads/sec, the read path dominates. This means we must optimize for fast lookups: aggressive caching (Redis), read replicas, and potentially CDN edge caching for popular URLs.
~200 writes/sec, ~20,000 reads/sec. Optimize the read path first.
Concepts from this question2 concepts unlocked
★
Read-Heavy Caching (Cache-Aside)
STANDARDA caching pattern where the application checks the cache first, falls back to the database on a miss, and populates the cache before returning. Ideal for read-heavy workloads.
Hit rate≥80%⟹DB load reduced by 5× URL shorteners have a 100:1 read:write ratio. Caching the top 20% of URLs serves 80% of traffic (Zipf distribution), dramatically reducing database load.
An encoding scheme using 62 characters [a-zA-Z0-9] to convert numeric IDs into compact alphanumeric strings. Each character represents a digit in base-62.
62n unique codes for n characters⟹627≈3.5×1012 Base62 maps auto-incrementing IDs to short, URL-safe strings with zero collision probability. It is the preferred encoding for most URL shortener designs.