Quick Start

50-Minute Interview Framework

A 50-minute system design interview goes by very fast.
If you do not manage time well, you may spend too long on requirements and never reach the deep dive. This article gives you a simple structure to follow.

The 50-minute structure

Use this as your default interview plan.

This is not a strict script. Some interviews are shorter or longer. But this structure keeps you from getting lost.

Step 1: Clarify requirements

Start by asking a few targeted questions.

You want to know:

What are the core features?
Who are the users?
What is the expected scale?
What latency or availability do we need?
Is strong consistency required?
Are there features we should ignore for now?

Do not ask 20 questions. Ask the important ones.

For example, if the prompt is “Design a URL shortener,” good questions are:

Do users need custom aliases?
Do short URLs expire?
What is the expected read and write traffic?
Should redirects be very low latency?
Do we need analytics?

Then quickly state your scope:

I will focus on URL creation and fast redirect. I will treat analytics as optional unless we have time.

Step 2: Core entities and APIs

Next, define the main objects in the system.

For URL shortener, the core entity is simple:

URL Mapping
- short_code
- long_url
- user_id
- created_at
- expires_at

Then design simple APIs.

POST /urls
GET /{short_code}

You do not need perfect API design. You just need a clear contract.

A good phrase:

I’ll define the APIs first so we are clear on what the system needs to support.

Step 3: High-level design

The high-level design should be simple.

At this stage, do not over-optimize.

For example:

Client → URL Service → Database

For URL creation:

Client sends long URL
URL Service generates short code
URL Service stores mapping in database
Client receives short URL

For redirect:

Client visits short URL
URL Service looks up short code in database
URL Service returns HTTP redirect

This design is not scalable yet. That is okay.

The goal of high-level design is to make the system work first.

Step 4: Deep dives

Deep dive is where the interview becomes important.

This is where you show technical depth.

For URL shortener, good deep dives could be:

How to generate unique short codes.
How to make redirects fast.
How to scale reads and storage.
How to handle expired URLs.
How to prevent abuse.

Use this format:

Problem → Simple solution → Better solution → Tradeoff

Example:

The simple design hits the database on every redirect. At 10B redirects per day, that becomes expensive and slow. I would add a cache in front of the database. Since URL mappings are mostly immutable, cache invalidation is simple. The tradeoff is that expired URLs need careful TTL handling.

This kind of answer is much stronger than just saying:

Add Redis.

Step 5: Wrap up

At the end, summarize your design.

A good wrap-up sounds like this:

To summarize, we designed a URL shortener with a URL Service, a database for mappings, a cache for fast redirects, and a counter-based approach for unique short codes. The main tradeoffs are cache freshness, global uniqueness, and storage growth. If we had more time, I would go deeper into analytics and abuse prevention.

This shows the interviewer that you understand the full design.