System design interview: the URL shortener, simulated live

Stackrig · 30 September 2026

1. Requirements and estimates

• Functional: create a short link for a long URL; redirect a short link to the long URL. Optional: custom aliases, expiry, click counts.
• Non-functional: redirects fast (a few ms at the server) and highly available; links never lost.
• Traffic: assume 2,000 requests/s on average, 2× that at the daily peak, and 2 % of requests create links. That is 40 new links/s, about 3.5 million a day and 1.3 billion a year.
• Keys: 7 characters of base62 give 62⁷ ≈ 3.5 trillion codes, enough for thousands of years at that rate.
• Storage: at about 500 bytes per link (URL, code, timestamps, owner), 1.3 billion links are roughly 650 GB a year. One database handles that; plan partitioning by code for later.

2. The design

Users → CDN → Load balancer → Redirect API (3 servers) → Redis (hot links) → Postgres (all links)
                                        └──── creates (2 %) ────────────────→ Postgres

• CDN caches redirect responses at the edge. With a short TTL it answers 60 % of the redirects in our design; the rest reach the API.
• Redirect API: stateless, 3 × c7i.xlarge (4 vCPU) on AWS, about 2 ms of CPU per redirect.
• Redis answers 95 % of the lookups that reach the API: link popularity is very skewed.
• Postgres (db.r7g.large) stores every link, serves the cache misses and takes the writes.
• Short codes: a counter encoded in base62, with each API server reserving ranges of the counter so they never collide. Hashing the URL also works but needs a collision check; random codes need one too.

3. Run it: what breaks first?

We built this design as a template in Stackrig and turned the traffic dial. These are Stackrig model results for that design, with a traffic curve that peaks at 2× the average:

The database is not the bottleneck: Redis and the CDN shield it. The API tier is, because every CDN miss is a request it must serve. There are two fixes. More servers cost money every month. A higher CDN hit ratio, from a longer TTL on redirects, costs nothing and cuts the API's traffic in half (40 % misses become 20 %).

4. The part most answers skip: cost

At 1× the design costs about $10,400 a month in Stackrig's AWS price tables, and about $9,100 of that is the CDN: billions of redirect requests a month at a per-request price. The servers are cheap by comparison. That changes the trade-offs you can discuss:

• 301 or 302? A 301 (permanent) can be cached by browsers and the CDN, so repeat clicks cost you nothing, but you stop seeing them. A 302 (temporary) reaches you every time and lets you count clicks, at the price of more CDN and API traffic. Say which one you pick and why.
• Analytics: if click counts matter, log them asynchronously (a queue and a worker), never in the redirect path.
• Cache TTL: links rarely change, so long TTLs are safe, except for deleted or expired links, which need an invalidation path.

5. Interview checklist

1. Clarify the read/write ratio and the peak, then estimate requests/s, storage and key space.
2. Draw the read path first (it is 98 % of the traffic), then the write path.
3. Name the first bottleneck and what you would watch (API CPU at the peak, cache hit ratios).
4. Give two fixes with their cost, and pick the cheaper one.
5. Close with failure cases: cache flush (every read hits the database), CDN outage, a hot link.

Why simulate an interview design?

Reading about a design teaches you the boxes. Running it shows you which box breaks at 4× traffic, what a cache flush does to the database and what the fix costs, and you remember that. Stackrig has the URL shortener and ten other designs as templates, each with one lesson you can reproduce in a minute. Its numbers are model results; how they compare with an exact simulation and real machines is published on How accurate is Stackrig?

Open “URL shortener” in the playground Watch the live demo Get early access

More

• How many requests per second can one Postgres handle?
• Retry storms: why retries take your service down