How a System Design Interview Works

A system design interview is not a quiz with one right answer. The interviewer gives you a deliberately vague product, such as “Design a URL shortener” or “Design WhatsApp”, and watches how you turn it into a working architecture. They are checking three things:

Can you scope a problem? You ask the right questions instead of designing everything at once.
Do you know the building blocks? Load balancers, caches, databases, queues and CDNs, and when each one helps.
Can you reason about trade-offs? Every choice costs something. Strong candidates say what they gave up and why.

The good news is that almost every question can be answered with the same four steps.

flowchart LR
  A["1. Requirements<br/>(5 min)"] --> B["2. Estimates<br/>(5 min)"]
  B --> C["3. High-level design<br/>(15 min)"]
  C --> D["4. Deep dives<br/>(15–20 min)"]

Step 1: Clarify the requirements

Start by asking questions. Split what you learn into two lists.

Functional requirements describe what the system does. For a URL shortener:

Given a long URL, return a short one.
Visiting the short URL redirects to the long one.
(Maybe) custom aliases, expiry dates, click analytics.

Non-functional requirements describe how well it does it:

Scale: how many users, how many requests per second?
Latency: how fast must a redirect be?
Availability: can it ever be down? (A redirect service that is down breaks every link on the internet that uses it.)
Consistency: is it acceptable for a new link to take a few seconds to work everywhere?
Durability: can we ever lose a link? (No.)

Write both lists on the board. Then agree on the two or three core features you will actually design. Interviewers like it when you say “I’ll leave analytics for the end if we have time.”

Step 2: Back-of-the-envelope estimates

Rough numbers tell you which parts of the system are hard. Estimate:

Requests per second for reads and writes. One day has about 86,400 seconds; round to 100,000 (10⁵) to make mental maths easy.
Storage over a few years.
Bandwidth in and out.
Memory needed if you cache the hot data.

You are not graded on exact arithmetic. The point is to reach conclusions like “reads are 100× writes, so caching matters more than write throughput” or “we’ll store 30 TB over five years, which is too much for one database machine.” The next lesson covers estimation in detail.

Step 3: High-level design

Draw the simplest design that meets the functional requirements, then evolve it. Most designs start like this:

flowchart LR
  U[Clients] --> LB[Load balancer]
  LB --> S1[App server]
  LB --> S2[App server]
  S1 --> C[(Cache)]
  S2 --> C
  S1 --> DB[(Database)]
  S2 --> DB

Walk through one request end to end: “The client sends POST /links; the load balancer routes it to any app server; the server generates a short code, writes it to the database and returns it.” Then define the API (endpoints, request and response) and the data model (tables or documents, and the keys you look things up by).

Step 4: Deep dives

Now the interviewer will push on the weak spots, or ask you to pick some. Typical deep dives:

How exactly do you generate unique short codes without collisions?
What happens when the database can’t keep up with writes? (Replication, sharding.)
How do you keep the cache consistent with the database?
What happens when a server or a whole data centre fails?
How do you stop one user from flooding the system? (Rate limiting.)

For each one, give two options and the trade-off, then choose. For example: “We could use a relational database with a unique index; that’s simple but sharding it is manual. Or a key-value store like DynamoDB that shards automatically but gives us fewer query options. Since we only ever look links up by code, I’d pick the key-value store.”

What interviewers want to hear

Weak answer	Strong answer
“We’ll use MongoDB because it scales.”	“Our access pattern is a single key lookup at 10K reads/sec, so any key-value store works; I’d pick X because…”
Draws 15 boxes in the first five minutes	Starts with three boxes and adds components only when a requirement forces it
“We’ll add a cache.”	“We’ll cache the top 20% of links in Redis, about 50 GB; a miss falls through to the DB; entries expire after 24 h.”
Ignores failure	“If the cache cluster dies, the DB sees 10× the load, so we’ll…”

A checklist to carry into every interview

Functional requirements: the core 2–3 features.
Non-functional requirements: scale, latency, availability, consistency, durability.
Estimates: QPS (read and write), storage, bandwidth, cache size.
API: the endpoints and their parameters.
Data model: entities, keys and indexes.
High-level diagram: walk one request through it.
Deep dives: bottlenecks, scaling, failure, consistency.
Wrap-up: what you would add next (monitoring, analytics, multi-region).

The rest of this module teaches the building blocks you need for steps 3 and 4, then applies the framework to the classic questions.

Step 1: Clarify the requirements

Step 2: Back-of-the-envelope estimates

Step 3: High-level design

Step 4: Deep dives

What interviewers want to hear

A checklist to carry into every interview

Check yourself