A System Designer guide

URL shortener walkthrough

Separate durable link storage from fast redirects, estimate the read path and test what happens when a popular link outgrows its cache.

By System Designer · 7 November 2026

This walkthrough uses the URL shortener scenario. Try an attempt first if you want to make your own choices before reading a possible approach.

Requirements and scale

People paste a long web address and get back a short one. Millions of other people then tap that short link, so reading is almost everything. Keep every tap fast, and never lose a link.

Who uses it: 50 million people a month
Audience in plain numbers: 50,000,000 people per month
Normal peak: ≈ 5,000 requests per second
Request mix: Read: 99%; Write: 1%
Speed for 99 of 100 requests: Read: ≈ 200 ms; Write: ≈ 200 ms
Successful requests: 99.9%
Data safety: No acknowledged write may be lost.
Monthly budget: ≈ $12,000
Data at rest: ≈ 1.5 TB
Where users are: North America: 70%; Europe: 30%
Home region: North America
Waiting deadlines: Read: 900 seconds; Write: 3,600 seconds

≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.

Short codes are 7 characters. Each stored link uses about 0.5 KB including its metadata (approx.).
About 20 new links a second on average (≈ 50 million a month, approx.).
One app server handles about 1,000 requests a second (approx.).

Estimates to work through

Reads per second at peak: ≈ 4,950 req/s. 5,000 × 0.99 (approx.)
App servers for the evening peak: ≈ 5 servers. 5,000 req/s ÷ about 1,000 per server = 5. Run at least 6, and 7 or 8 so each sits near 70 percent, and turn on autoscaling: the 3 times spike needs about 15 (approx.).
Storage after 5 years: ≈ 1.5 TB. 50 million links a month × 12 × 5 years × 0.5 KB each ≈ 1.5 TB (approx.)
Possible 7-character codes: ≈ 3,500,000,000,000 codes. 62 letters and digits, to the power of 7 ≈ 3.5 trillion, so we will not run out (approx.)

Start with the lookup, not the short code

A redirect is a lookup from a short code to a long address. Saving a link creates the durable record. Following a link should do as little work as possible. In this scenario the mapping never changes, so a previously fetched answer remains useful.

Choose how a new code becomes unique. A random code needs collision detection and a retry; a sequence is simple but guessable and needs an allocation policy. Persist the mapping before acknowledging creation. A fast redirect path cannot recover a link that was never safely stored.

A design that holds

Keep the mappings in a key-value store, which retrieves a record by its key. Put application servers behind a load balancer so no single server takes every request. A memory cache serves repeated lookups. Public, immutable redirects may also be served from edge copies close to users, reducing both origin work and travel time.

Follow both paths. A cache hit ends early. A miss reaches the authoritative mapping, then fills a copy. When many callers miss the same link, combine their fetches rather than asking the store once per caller. Collect click analytics after the redirect so a slow counter does not delay navigation.

The trade-offs

A long cache lifetime works because the mapping is immutable. That same policy would need reconsidering if links could be edited, revoked or made private. Edge copies cost money per request and introduce another policy to operate. A server-only path can be cheaper but sends more work and network travel through the origin.

What breaks it

The important test is not just warm-cache throughput. Empty the cache while a popular link is being opened. Look for the load that moves back to the store, and check whether autoscaling starts quickly enough. Keep spare capacity for the interval before new servers are ready.

Study Remembering answers and Copies near users, then try the URL shortener. Make a baseline run, change one caching decision and compare the affected path. Explain which result would make you choose the simpler server-only design.

The day that tests the design

Consumer traffic, busiest in the evening. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

19:30 · Viral spike
A post blows up. Traffic climbs to several times normal within minutes.
Traffic reaches 3 times the scheduled load; rises over 600 seconds, holds for 3,600 seconds and eases over 3,600 seconds.
12:10 · Cache stampede
The cache empties (restart, purge, mass expiry) and every request rushes to the database at once.
Recovery window: ≈ 300 seconds.

Play this problem. Keep one baseline, predict a change and compare the next full day. The in-game editorial has calibrated reference designs after you finish a traffic day.