LeetPrep

How to Approach a System Design Interview: URL Shortener Example

Published October 18, 2026 · 2 min read

System design interviews are open-ended, which makes them stressful. A repeatable structure keeps you calm and shows the interviewer how you think. Here is a framework, followed by a worked example: a URL shortener like bit.ly.

A five-step framework

  1. Clarify requirements. Separate functional requirements (what the system does) from non-functional ones (scale, latency, availability).
  2. Estimate scale. Rough numbers for traffic and storage guide your choices.
  3. Define the API and data model. Keep it small and concrete.
  4. Draw the high-level design. Clients, servers, database, cache, and how they connect.
  5. Dive deeper and discuss trade-offs. Bottlenecks, failure cases, and alternatives.

Example: URL shortener

1. Requirements

Users can create a short link for a long URL, and visiting the short link redirects to the original. Optional: custom aliases and link expiry. The system should be highly available, and redirects should be fast.

2. Estimates

Suppose 100 million new URLs per month. That is about 100,000,000 / (30 x 86,400), or roughly 40 writes per second. If reads are 100 times more common than writes, expect about 4,000 redirects per second. At roughly 500 bytes per record, 100 million records a month is about 50 GB per month, which is easily manageable.

3. API and data model

  • POST /urls with the long URL returns a short code.
  • GET /{code} responds with an HTTP redirect.
  • Table: code (primary key), long_url, created_at, expires_at.

4. Generating the short code

A 7-character code using base62 (a-z, A-Z, 0-9) gives 627, about 3.5 trillion combinations, which is plenty. Options: encode an auto-incrementing ID in base62 (simple, but predictable), or generate random codes and retry on collision. A separate ID service or pre-generated key pool avoids a single bottleneck.

5. Scaling and trade-offs

  • Put a cache (for example Redis) in front of the database, because a small set of links gets most of the traffic.
  • Use a key-value or relational database partitioned by code once one machine is not enough.
  • Use a 301 redirect to let browsers cache, or a 302 redirect if you need to count every click.
  • Add rate limiting to prevent abuse, and replicate across regions for availability.

Tips

Think out loud, ask questions early, and say why you chose each component. There is rarely one correct design; interviewers want to see reasoning and awareness of trade-offs.