How to answer any system design question

The framework

1. Clarify requirements

   5 min

   Ask who the users are, which features are in scope and what “done” looks like. Separate functional requirements (shorten a URL, redirect) from non-functional ones (latency, availability, consistency, scale).

2. Estimate the scale

   5 min

   Rough numbers decide the design: requests per second, read/write ratio, data size per year, bandwidth. Round aggressively — one significant figure is enough.

3. Define the API

   5 min

   Write the main endpoints or events with inputs and outputs, e.g. POST /urls {longUrl} → {shortCode}. This pins down the contract before the boxes.

4. Model the data

   5 min

   List the main entities, their key fields and how they are queried. The access pattern drives the choice of database and keys.

5. Draw the high-level design

   10 min

   Clients, load balancer, services, databases, caches, queues. Walk one request end to end and make sure every requirement has a home.

6. Deep-dive the hard parts

   10 min

   Pick the two or three riskiest components — the hot path, the biggest table, the consistency boundary — and go deep: sharding, caching, failure handling.

7. Find bottlenecks & failures

   3 min

   What breaks at 10× traffic? What happens when a node, zone or dependency fails? Add replication, retries, circuit breakers or queues where needed.

8. Summarise trade-offs

   2 min

   Recap the design, the main trade-offs you made and what you would do next with more time. Interviewers value honest trade-offs over a perfect diagram.

Numbers for quick estimates

See Latency numbers & the memory hierarchy for more.

Worked example: a URL shortener

1. Requirements

• Create a short link for a long URL; redirect short links to the original.
• 100 million new links per month; reads outnumber writes 100 to 1.
• Redirects must be fast (p99 under 50 ms) and highly available.

2. Estimates

• Writes: 100M ÷ (30 × 86,400) ≈ 40 per second; reads ≈ 4,000 per second, peaks ~20,000.
• Storage: 100M × 12 months × 5 years × ~500 bytes ≈ 3 TB.
• Short code: 7 characters of base62 gives 62⁷ ≈ 3.5 trillion codes — plenty.

3. Design

4. Key decisions

• IDs: a distributed ID generator (or pre-allocated ranges per server) encoded in base62 — no collisions, no read-before-write.
• Storage: a key-value or wide-column store keyed by short code; simple lookups, easy to shard by key.
• Caching: popular codes in Redis and at the CDN edge; most redirects never reach the database.
• Redirect: 302 if you need click analytics on every visit, 301 if you want browsers to cache it.
• Analytics: publish click events to a queue and aggregate asynchronously, off the redirect path.

Practice problems