system-design · beginner

System Design Interview Answering Framework

Start here

System design interviews evaluate how you structure ambiguity: asking questions, making assumptions explicit, drawing a workable design, and improving it under scale and failure.

This lesson is a reusable answering framework—a spine for problems like URL shortener, chat, news feed, or rate limiter.

You should care because strong engineers still underperform when they jump to Kafka before requirements, or never discuss trade-offs.

What you will learn

Run a timed structure (about 35–45 minutes).
Separate functional vs non-functional requirements.
Do quick capacity estimates.
Start simple, then scale deliberately.
Talk failures, observability, and evolution.
Avoid common anti-patterns.

What you should know first

Topic	Why
System design foundations	Building blocks vocabulary
Core HTTP and storage concepts	Most prompts assume them

Words you need before we begin

Term	Plain English
Functional requirement	What the system should do for users.
Non-functional requirement	How well: latency, availability, consistency, cost.
Back-of-envelope estimate	Rough math for QPS, storage, bandwidth.
Bottleneck	Component that limits scale first.
Trade-off	A gain that costs something else.
MVP design	Smallest design that meets stated goals.

Simple story: planning a dinner for 8 vs 800

You ask dietary needs first (requirements), estimate grocery volume (scale), cook a sensible menu (MVP), then rent bigger ovens if needed (scale-out)—you do not start by buying a stadium kitchen for eight friends.

Timed framework

1) Clarify (5 minutes)

Ask:

Who are users? Read vs write heavy?
Core use cases? Out of scope?
Latency targets? Consistency needs?
Expected DAU, peak QPS, data size?

State assumptions aloud if interviewer is vague.

2) API and data model (5–8 minutes)

Sketch endpoints or main events.
Entities and keys for primary lookups.
Choose SQL/NoSQL with a reason tied to access patterns.

3) High-level design (8–10 minutes)

Draw: clients → load balancer → app → cache → DB → (async workers).

Narrate the request path for the primary use case end to end.

4) Deep dives (10–15 minutes)

Pick 2–3 bottlenecks:

Hot reads → cache
Writes → sharding/partitioning
Fan-out → queues
Search → separate index

Go one level deeper than boxes: what is cached, invalidation, partition key.

5) Reliability and ops (5 minutes)

Failure modes and degradations
Idempotency, retries, timeouts
Metrics/alerts
Multi-region only if needed

6) Wrap (2 minutes)

Summarize design, top trade-offs, and how you would evolve from day 1 to year 3.

Visual mental model

flowchart TB
  Q[Clarify requirements] --> E[Estimate scale]
  E --> M[MVP design]
  M --> D[Deepen bottlenecks]
  D --> F[Failures and ops]
  F --> S[Summarize trade-offs]

Learning question: Where do candidates most often skip and lose points?

Caption: Requirements, estimates, and failure talk—not only drawing Kafka.

Complete worked micro-example: “Design a pastebin”

Clarify

Anonymous paste create + retrieve by id; 1KB average; 10M pastes/day; read:write 5:1; public links.

Estimate

Writes ≈ 115/s average; reads ≈ 575/s; storage ≈ 10M × 1KB ≈ 10 GB/day raw.

MVP

API + app + SQL table pastes(id, body, created_at) + object storage optional for large blobs + cache for hot pastes.

Deepen

Id generation (UUID vs base62 counter ranges)
Cache TTL
Abuse rate limits

Failures

DB down: reads from cache partial; creates fail closed.

How interviewers listen

They listen for:

Collaborative clarification
Explicit assumptions
Structured communication
Correct-enough fundamentals
Trade-off language

Not for memorized FAANG diagrams alone.

Failure modes of interview performance

Mode	Symptom	Fix
Jump to buzzwords	Kafka first sentence	Start with requirements
No numbers	Hand-wavy scale	Always estimate
Silent drawing	Interviewer lost	Narrate constantly
Ignore failures	Happy path only	Force a failure minute
Over-design MVP	Unshippable monster	Two-phase design

Trade-offs to practice saying

Consistency vs latency
Cost vs headroom
Simplicity vs future flexibility
Build vs buy
Sync vs async

Common misunderstandings

“There is one correct design.” There are better-reasoned designs.
“More components mean higher score.” Complexity needs justification.
“Estimates must be perfect.” Order-of-magnitude is the point.
“Never change your design.” Updating after new constraints is good.
“Only seniors discuss ops.” Observability is fair game early.

Check your understanding

Name the six phases of the timed framework.
What is a non-functional requirement example?
Why estimate before sharding talk?
What should a wrap-up include?
Give one interview anti-pattern.

Practice

Run the framework on URL shortener with a timer.
Write five clarifying questions for a chat system.
Estimate storage for 1M users × 100 messages/day × 200 bytes.
List three bottlenecks for a news feed.
Record yourself explaining a design in 10 minutes.

Deeper production notes

Mapping interview to real jobs

Real design adds stakeholders, compliance, migrations, and org ownership. Interviews compress that into signals: prioritization, communication, and technical judgment.

Using this curriculum

After practicing the framework, drill specific primers (caching, queues, rate limits) so deep dives have substance.

Additional teaching scenarios

Scenario A — peak load day

Traffic multiplies by ten. Mark which failure modes appear first and the first mitigation for each.

Scenario B — mixed versions

Half the fleet runs an old build. Which assumptions break? Prefer one deploy window of compatibility.

Scenario C — five-sentence teach-back

Explain the core idea without acronyms using only the simple story and worked example.

Scenario D — metrics and alerts

List three metrics and one alert that track user impact or a scarce resource.

Scenario E — non-goals

Name two problems this technique should not solve.

Scenario F — ownership

Who owns dashboards, code, and pages? Blank means not ready for broad rollout.

Revision summary

Clarify → estimate → MVP → deepen → failures → summarize.
Make assumptions explicit.
Justify every major box.
Speak trade-offs and evolution.
Practice timed, out loud.

Glossary

Term	Definition
Answering framework	Structured approach to design interviews.
MVP design	Minimal viable architecture for stated goals.
Bottleneck	First limiting resource under load.

Abbreviations and terminology

DAU — Daily active users
QPS — Queries per second
SLO — Service level objective
MVP — Minimum viable product/design

What to learn next

Extra teaching notes for first-time builders

Write the single bottleneck you are protecting before picking tools. Name the signal that tells you the design is working for users, not only that internal counters move. When reviewing a change related to this lesson, ask what happens when the component is slow for ten minutes, down entirely, or running twice. Prefer small explicit failure modes that operators can understand at 3 a.m.

Document ownership for dashboards, code, and pages. Undocumented mechanisms become folklore and then outages. Prefer designs that tolerate mixed versions for at least one deploy window so rollouts do not require perfect global simultaneity.

Napkin math helps: estimate peak rate, multiply by payload size, and ask whether the design still holds when a dependency is at half capacity. If the answer depends on luck, add bounds, backpressure, or shedding before production traffic arrives.

Extra teaching notes for first-time builders

FAQ from first-time learners

Q: How detailed should drawings be?
A: Enough to show data flow and storage; not every class.

Q: What if I do not know a technology?
A: State the requirement it fulfills and a simpler alternative.

Q: Should I mention specific cloud products?
A: Optional; prefer concepts first, products as examples.

Track: Distributed Systems

By Shubham Jain

All articles · Study paths

Shubham Jain · Learning Lab