How to Answer a System Design Interview Question

"Design YouTube" sounds impossible in 45 minutes. It is meant to. The interviewer does not expect a finished system. They want to see how you think, how you handle unclear problems, and whether you can explain trade-offs.

A framework#

Step 1: Clarify requirements#

Never start drawing straight away. Ask questions, and write the answers down.

Functional:

• Who are the users?
• What are the two or three core features?
• What is out of scope?

Non-functional:

• How many users, and how many requests?
• Is it read-heavy or write-heavy?
• What matters most: latency, consistency or availability?

Then state your scope: "I will focus on posting a link and redirecting. I will leave out accounts and analytics, unless you would like them."

Step 2: Estimate scale#

Rough numbers decide the design. You want the order of magnitude: is it 100 requests a second, or 100,000? The next lesson shows how.

Step 3: API and data model#

Name the main endpoints, and the key tables:

POST /links   { url }           --> { code }
GET  /{code}                    --> 301 redirect

links(code PK, url, created_at, user_id)

This keeps you and the interviewer talking about the same system.

Step 4: High-level design#

Draw the path of a request. Start with something simple that works, then improve it:

Client --> Load balancer --> App servers --> Cache --> Database

Talk through the main flows out loud: "When a user creates a link, the request goes to ..."

Step 5: Deep dive#

Choose the hardest parts, or ask the interviewer which interest them. Useful prompts to yourself:

• How does it scale by 10 times?
• What happens if each component fails?
• Where is the bottleneck?
• How is data kept consistent?

Step 6: Wrap up#

Summarise the design, name its weaknesses, and say what you would do with more time: monitoring, security, costs.

What interviewers look for#

Useful phrases#

• "Before I start, can I check a few requirements?"
• "I will assume 10 million daily users. Does that sound right?"
• "The trade-off here is ... so I would choose ... because ..."
• "A simple version would be ... and if traffic grows, I would add ..."

Common mistakes#

Practice#

Key takeaway#

Next: Back-of-the-Envelope Estimation.