The System Design Interview — A Practical Framework

The system design interview is not testing whether you have memorised an architecture. It is testing whether you can take a vague problem, ask the right questions, and reason out loud about trade-offs. Here is a framework that works for almost any prompt.

The 45-minute structure

Rough time budget for a standard round:

1. Requirements and scope — 5 min
2. Estimates — 3 min
3. High-level design — 10 min
4. Data model and API — 8 min
5. Deep dive on 1–2 components — 12 min
6. Bottlenecks, trade-offs, wrap-up — 5 min

The single biggest mistake is jumping to boxes and arrows before step 1.

1. Requirements and scope

Ask questions until the problem is concrete. For "design Twitter":

• Functional: post a tweet, follow users, view a home timeline. Are replies, likes, search, media, notifications in scope? Get the interviewer to cut it down.
• Non-functional: how many users? read-heavy or write-heavy? (timelines are extremely read-heavy). What latency is acceptable for the timeline? How consistent does it need to be — is a few seconds of staleness fine? (usually yes)
• Out of scope: say what you are *not* doing, so you are not judged for omitting it.

Write the agreed scope down where you both can see it.

2. Estimates

Back-of-envelope numbers justify your design choices later.

• Users: 300M total, 150M daily active.
• Writes: each posts ~2 tweets/day → ~300M tweets/day → ~3,500 writes/sec average, maybe 10x at peak.
• Reads: each opens the timeline ~10 times/day → 1.5B reads/day → ~17,000 reads/sec, higher at peak.
• Storage: 300M tweets/day × ~300 bytes ≈ 90 GB/day of tweet text, before media and indexes.

The takeaway: reads dominate writes by ~5x, so the design should optimise the read path.

3. High-level design

Sketch the main components and the request flow:

• Clients → load balancer → stateless API servers.
• Write path: API → tweet service → write to the tweets store → enqueue a "fan-out" job.
• Read path: API → timeline service → read a precomputed timeline from a cache.
• Stores: a database for tweets and the social graph, a cache (Redis) for timelines, object storage + CDN for media, a message queue between write and fan-out.

Explain *why*: the timeline is read far more than it is written, so we do the expensive work (assembling a timeline) at write time and make reads a simple cache lookup.

4. Data model and API

Core tables/collections:

• tweets(id, user_id, text, created_at, media_url)
• follows(follower_id, followee_id, created_at)
• timelines(user_id, tweet_ids...) — in the cache, not the DB

API:

• POST /tweets — body { text }, auth from the token.
• GET /timeline?cursor=... — returns a page of tweets, cursor-based pagination (not offset — offset breaks as data shifts).
• POST /follow/{userId} / DELETE /follow/{userId}.

Mention id generation (Snowflake-style: time-ordered, sortable, no central bottleneck).

5. Deep dive: timeline fan-out

This is where the interesting trade-off lives.

Fan-out on write (push): when a user tweets, append the tweet id to every follower's cached timeline. Reads are trivial. But a celebrity with 50M followers causes 50M cache writes per tweet — a "hot user" problem.

Fan-out on read (pull): store nothing; when a user opens their timeline, fetch recent tweets from everyone they follow and merge. No write amplification, but reads are expensive and slow for users who follow thousands of accounts.

The real answer is hybrid: push for normal users, pull for the handful of celebrity accounts, and merge the two at read time. Say this explicitly — recognising that neither pure approach works is the point of the question.

6. Bottlenecks and trade-offs

Name the weak points before the interviewer does:

• The cache is the read path — if it goes down, the DB gets hammered. Mitigate with replication and a fallback to a degraded pull-based timeline.
• Fan-out queue backlog during a spike delays timelines. Mitigate with autoscaling consumers and prioritising active users.
• Consistency: a new follow may take seconds to show tweets. That is an acceptable trade for the read performance.
• Storage growth: tweets are append-only and huge. Partition by time, move old data to cheaper storage, keep only recent timelines in cache.

How to talk during the interview

• Think out loud. Silence reads as being stuck. Narrate your reasoning even when you are unsure.
• State assumptions and move on rather than waiting for permission.
• Drive the conversation — propose the next step ("let me design the data model now") instead of waiting to be prompted.
• When you don't know something, say so, then reason from first principles. "I haven't used Kafka's exactly-once semantics in anger, but the guarantee we need here is..."

Common prompts to practise

URL shortener, rate limiter, news feed, chat/messaging, file storage (Dropbox), ride-hailing dispatch, notification system, a typeahead/search suggestion service. Do each one against the framework above until the structure is automatic.

Practising with feedback

You can read every system design article and still freeze in the room, because the skill is the live conversation. A mock interview with a senior engineer who runs these for real — with honest feedback on your scoping, your trade-off reasoning and your communication — is the fastest way to get ready.

Frequently asked questions