A Step-by-Step Framework for System Design Interviews

System design interviews are open-ended by design. There's no single right answer, which is exactly why they're hard: without a plan it's easy to jump into databases before you know what you're building, or to spend 30 minutes on one box of the diagram.

This framework gives your 45 minutes a shape. It works for most product-style questions: design a URL shortener, a chat app, a news feed, a rate limiter.

The framework at a glance

Step	Time	Goal
1. Clarify requirements	5 min	Agree on what you're building
2. Estimate scale	3–5 min	Know which problems actually matter
3. Define the API and data model	5 min	Pin down the contract
4. High-level design	10 min	A working end-to-end system
5. Deep dives	15 min	Solve the hard parts properly
6. Wrap up	3–5 min	Bottlenecks, trade-offs, what's next

We'll walk through it with a classic: design a URL shortener.

1. Clarify requirements

Split them into functional (what it does) and non-functional (how well it does it). Ask, don't assume.

Functional:

• Users submit a long URL and get a short one.
• Visiting the short URL redirects to the original.
• Optional: custom aliases, expiration, click analytics.

Non-functional:

• Redirects must be fast and highly available, since they're on the critical path for every click.
• Short links should be hard to guess? (Ask: this changes the ID design.)
• Reads vastly outnumber writes.

Then confirm what's out of scope. "I'll skip user accounts and analytics unless you'd like me to cover them" keeps you focused and shows you can prioritize.

2. Estimate scale

Back-of-the-envelope numbers tell you whether you need sharding, caching or neither. Say your assumptions out loud.

• 100 million new links a month is about 40 writes per second.
• With a 100:1 read-to-write ratio, that's about 4,000 redirects per second, with peaks several times higher.
• Each record is roughly 500 bytes, so 100 million links a month is about 50 GB a month, or around 3 TB over five years.

Conclusion: writes are easy; reads and storage growth are the real problems. That tells you where to spend your deep-dive time.

3. Define the API and data model

Keep the API small:

POST /urls        { longUrl, alias?, expiresAt? }  ->  { shortCode }
GET  /{shortCode}                                  ->  301/302 redirect

Data model:

links(short_code PK, long_url, created_at, expires_at, owner_id)

Mention the redirect status code choice: 301 lets browsers cache the redirect (less load, but you lose click analytics), 302 sends every click through you.

4. High-level design

Draw the simplest system that works end to end:

1. Clients call a load balancer.
2. Stateless API servers handle create and redirect.
3. A key-value store holds short_code → long_url. The access pattern is pure key lookups, which suits DynamoDB, Cassandra, or Postgres with an index at moderate scale.
4. A cache such as Redis sits in front of the store for hot links.
5. A short-code generator produces unique codes.

Walk one request through the diagram: "A redirect hits the load balancer, an API server checks Redis, falls back to the database on a miss, then returns a 302."

5. Deep dives

Pick the two or three hardest problems, ideally the ones your estimates pointed to, and solve them properly. Ask the interviewer which they care about most.

Generating short codes

• Hash the long URL (for example, the first 7 characters of a base62 hash): simple, but collisions need handling, and the same URL always maps to the same code.
• Counter plus base62 encoding: guaranteed unique and short. Seven base62 characters give about 3.5 trillion codes. A single counter is a bottleneck and makes codes predictable, so hand out ranges of IDs to each server and optionally shuffle the bits.
• Random codes with a uniqueness check: unpredictable, at the cost of a lookup per write.

State which you'd choose and why, given the requirements from step 1.

Scaling reads

• Cache hot links. Link popularity is extremely skewed, so a modest cache absorbs most traffic.
• Use read replicas, or a distributed store partitioned by short code.
• Put the redirect behind a CDN or edge function for the most popular links.

Expiration and cleanup

Store expires_at, check it on read, and run a background job to delete expired rows in batches so cleanup doesn't compete with live traffic.

6. Wrap up

Finish by stepping back:

• Bottlenecks: "If a single link goes viral, the cache handles it; if the cache cluster fails, the database would see a spike, so I'd add request coalescing."
• Trade-offs you made: "I chose a counter over hashing for guaranteed uniqueness, accepting that I need range allocation."
• What you'd add next: analytics through an async event stream, abuse detection, and multi-region replication.

Habits that make a strong impression

• Drive the conversation. Propose the next step instead of waiting to be asked.
• Think out loud about trade-offs. "We could do X or Y; X is simpler but Y scales better past N requests per second."
• Use numbers. Even rough ones show you're designing for reality.
• Check in. "Does this level of detail work, or should I go deeper on storage?"
• Don't over-engineer early. Start simple, then scale the parts your estimates say will break.

How to practice

Pick ten common questions (URL shortener, rate limiter, chat, news feed, file storage, notifications, search autocomplete, ride sharing, video streaming, a metrics system) and run each one against this framework on a timer. Write a one-page summary afterwards: requirements, numbers, diagram and the three key trade-offs. Those summaries make excellent review notes the night before an interview.

For the coding rounds in the same loop, see 12 coding interview patterns.