A worked estimate: the URL shortener

Let's estimate a complete system, step by step, the way you would in an interview, and turn each number into a decision.

The prompt: a URL shortener. Assumptions (state them; the interviewer can correct you):

• 100 million new short links a month.
• Each link is followed 100 times on average, so redirects outnumber creates 100 to 1.
• Links are kept for 5 years.
• Traffic peaks at about 3× the average.

Step 1: write rate

1 100M links / month ÷ 2.5 × 10^6 s/month ≈ 40 creates/s average
2 peak ≈ 3 × 40 = 120 creates/s

Decision: writes are tiny. A single relational database handles 120 inserts a second with ease. No need for a write-optimized or sharded store because of writes.

Step 2: read rate

1 40 creates/s × 100 = 4,000 redirects/s average
2 peak ≈ 12,000 redirects/s

Decision: 12,000 primary-key lookups a second is at or beyond what one database should do comfortably, and the latency target is tight. Reads need a cache (and/or replicas), and several stateless servers behind a load balancer.

Step 3: storage

1 row ≈ 7 B code + ~100 B URL + timestamps + overhead ≈ 500 B
2 100M × 12 months × 5 years = 6 × 10^9 links
3 6 × 10^9 × 500 B = 3 × 10^12 B ≈ 3 TB

Decision: 3 TB over five years, maybe 9 TB replicated. That is large for one machine's RAM but fine on disk. A single database can hold it, or it shards cleanly by code later. Old links might move to cheaper storage.

Step 4: how long must the codes be?

1 base62 alphabet: a–z, A–Z, 0–9 = 62 characters
2 62^6 ≈ 5.7 × 10^10  (57 billion)
3 62^7 ≈ 3.5 × 10^12  (3.5 trillion)

We need 6 billion over five years. Six characters would be enough on paper, but random codes start colliding long before a space fills up, so seven characters leaves comfortable room.

Step 5: cache size

Redirect traffic is highly skewed: most clicks go to recent and viral links. Suppose 20% of links get 80% of traffic, and we cache the links accessed in a day:

1 4,000 redirects/s × 10^5 s ≈ 4 × 10^8 redirects/day
2 unique links among them: say 10^8
3 cache 20% of those: 2 × 10^7 links × 500 B ≈ 10 GB

Decision: about 10 GB of hot links fits in RAM on a single Redis node, and a replica gives availability. With a high hit rate, the database sees a small fraction of the 12,000 reads a second.

Step 6: bandwidth

1 12,000 redirects/s × ~500 B response ≈ 6 MB/s

Decision: negligible. No CDN needed for the redirects themselves (though a CDN or edge cache can still cut latency for users far from the data center).

What the estimate built

Here is that design with the estimated peak (12,000 redirects and 120 creates a second) and ten API servers. Run it, then switch the scenario to Cold cache and watch what happens to the database when the cache restarts empty.

That table is the payoff. An estimate is worth doing exactly when each number ends with "…so we will…".