How to Approach System Design - High-Level Design

The biggest mistake in system design interviews? Jumping straight to drawing boxes. We need a framework — a repeatable process that works for any problem, from “Design a URL Shortener” to “Design Netflix.”

The 5-Step Framework

45-Minute System Design Framework

Step 1 (5 min): Requirements & Scope

└── Ask questions. Narrow the problem down.

Step 2 (5 min): Back-of-the-Envelope Estimation

└── QPS, storage, bandwidth. Ballpark numbers.

Step 3 (15 min): High-Level Design

└── Draw the core components. APIs. Data flow.

Step 4 (15 min): Deep Dive

└── Pick 2-3 areas. Go deep. Discuss trade-offs.

Step 5 (5 min): Wrap Up & Improvements

└── Bottlenecks, scaling, monitoring, future work.

Let’s walk through each step.

Step 1: Requirements & Scope (5 min)

Never start designing without asking questions first. The interviewer gives us a vague prompt on purpose — they want to see if we can narrow it down.

Ask about:

Users: How many? What kind?
Features: Which ones are core? Which can we skip?
Scale: Is this for 1,000 users or 1 billion?
Constraints: Latency requirements? Availability needs?

For “Design Twitter,” we might say: “Let’s focus on the tweet feed, posting tweets, and following users. We’ll target 200M daily active users.”

Step 2: Back-of-the-Envelope Estimation (5 min)

Quick math to understand the scale. We’re not aiming for exact numbers — just the right order of magnitude.

QPS (Queries Per Second): How many requests per second?
Storage: How much data do we store per day/year?
Bandwidth: How much data flows in and out?

This tells us whether we need one server or a thousand. We cover this in detail in a separate note.

Step 3: High-Level Design (15 min)

This is where we draw the architecture. Start simple and add complexity only when needed.

Draw the core components (clients, servers, databases, caches)
Define the API endpoints (what calls what)
Show the data flow (how a request travels through the system)
Pick the database type (SQL vs NoSQL, and why)

Keep it simple. We can always add more later.

Step 4: Deep Dive (15 min)

The interviewer will say something like “Let’s dig into X” or we can proactively pick 2-3 areas. This is where we show depth.

Common deep-dive areas:

Database schema and indexing
Caching strategy
How we handle failures
Data partitioning / sharding
Consistency vs availability trade-offs

This is the most important step. It’s where trade-off discussions happen.

Step 5: Wrap Up (5 min)

Summarize and show we’re thinking about the future:

Bottlenecks: What could break first?
Monitoring: How would we know something is wrong?
Scaling: What changes at 10x or 100x current scale?
Nice-to-haves: Features we scoped out but could add later

Common Mistakes

Jumping to the solution — Not asking questions first. This is the #1 red flag.
Over-engineering — Designing for Google scale when the problem says “small startup.”
Silence — Not talking while thinking. The interviewer can’t read our mind.
No trade-offs — Every decision has pros and cons. Always mention them.
Ignoring the interviewer — If they’re nudging us somewhere, follow the hint.

The Golden Rule

In simple language, system design interviews are a conversation. We talk, the interviewer responds, we adjust. It’s collaborative, not adversarial. The framework gives us structure, but we should stay flexible and follow where the discussion goes.