System Design Interviews A step by step guide

Mechanism first: numbers pick the architecture, not adjectives

A system-design interview is won by turning a vague prompt into quantities, because every quantity you estimate forces exactly one design decision. "Twitter is read-heavy" is an opinion; "11.6k timeline reads/s versus 4.6k tweet writes/s, and each read must merge every account you follow" is a fact that tells you to precompute timelines. The estimation step is not a ritual — it is the machine that converts requirements into an architecture. Skip it and every later choice is a guess.

The interview arc (RESHADED)

Good candidates run the same loop every time, so nothing important is skipped in the 35–45 minutes available:

1. Requirements — clarify scope and pin the functional + non-functional goals.
2. Estimation — back-of-envelope the scale (this is where the design decisions are born).
3. System interface (API) — nail the contract; it validates the requirements.
4. Data model — entities and relationships; foreshadows partitioning.
5. High-level design — 5–6 boxes end to end.
6. Detailed design — go deep on the 2–3 components the interviewer probes.
7. Evaluate — bottlenecks, single points of failure, and the trade-offs behind each choice.

Three things sink most candidates: the problem is open-ended with no single right answer, they lack hands-on large-system experience, and they under-prepare. The arc above is the antidote to all three — it gives structure, forces you to reason from scale, and makes trade-offs explicit.

Step 1 — Requirements (scope it before you scale it)

Design questions are deliberately ambiguous, so define the end goals first. For a Twitter-like service, resolve at least:

• Can users post tweets and follow others? Do we build and serve each user's home timeline?
• Do tweets carry photos/videos? (This alone changes the storage story by two orders of magnitude — see below.)
• Backend only, or front-end too? Is search and trending in scope? Push notifications?

Lock the scope, then estimate that scope — not an imaginary everything.

Step 2 — Back-of-envelope estimation (the worked example)

State the assumptions out loud, then compute. Assume 200M daily active users (DAU). A user opens the home timeline about 5 times a day and posts about 2 tweets a day. A tweet is ~300 bytes of text (plus metadata), and 10% of tweets carry a ~200 KB image. Peak traffic is ~2× the average. (Using decimal units: 1 GB = 10⁹ bytes, 1 TB = 10¹², a day = 86,400 s.)

Now walk it one line at a time — each row ends in the design decision its number forces:

Quantity	Arithmetic	Result	Decision it forces
Timeline reads	200M × 5/day = 1×10⁹/day; ÷ 86,400	≈ 11.6k reads/s avg; ×2 peak ≈ 23k reads/s	The read path is the hot path → cache + precompute it.
Tweet writes	200M × 2/day = 4×10⁸/day; ÷ 86,400	≈ 4.6k writes/s avg; ×2 peak ≈ 9.3k writes/s	Writes are lighter → we can afford extra work at write time.
Read : write ratio	11.6k : 4.6k (= 1×10⁹ : 4×10⁸)	≈ 2.5 : 1, read-dominated — and each read must merge all followees	Move the merge cost off the hot read path → fan-out-on-write.
Storage — text	4×10⁸ tweets/day × 300 B	= 120 GB/day → × 365 ≈ 44 TB/yr	Fits a sharded database; partition by user/tweet ID.
Storage — media	10% × 4×10⁸ = 4×10⁷ images/day × 200 KB	= 8 TB/day → ≈ 2.9 PB/yr (≈ 67× the text)	Media dwarfs text → object store + CDN; DB keeps only metadata/URLs.
Read bandwidth	23k reads/s × ~10 KB per timeline response	≈ 230 MB/s text egress from origin (media served by CDN)	CDN offload is mandatory; origin serves metadata, not bytes of media.
Cache memory	20% × 200M = 40M hot users × (500 tweet IDs × 8 B = 4 KB)	≈ 160 GB of hot timelines	A dedicated in-memory (Redis) timeline tier, sharded by user ID.

Notice the chain: users → QPS → ratio → storage → bandwidth → cache, and each output is an input to a concrete architectural choice. That is the whole point — an estimate that does not end in a decision is wasted time. The diagram below traces the same chain end to end.

Steps 3–5 — API, data model, high-level design

API locks the contract and cross-checks the requirements:

postTweet(user_id, tweet_data, media_url, location, timestamp, ...)
getTimeline(user_id, cursor, count)          // served from the precomputed cache
markFavorite(user_id, tweet_id, timestamp)

Data model — the entities, chosen so the hot query (a user's timeline) is cheap:

• User: UserID, Name, Email, CreatedAt, LastLogin
• Tweet: TweetID (time-sortable), AuthorID, Content, MediaURL, Likes, CreatedAt
• Follow: FollowerID, FolloweeID (the graph that fan-out walks)

Tweet text and metadata go in a horizontally-partitioned store (a MySQL fleet sharded by ID, or Cassandra); media goes to a blob/object store fronted by a CDN — exactly because the estimation said media is ~67× the text. High-level design then follows the numbers: load balancers in front of stateless app servers, a write path that fans tweets into follower timeline caches, a read path that returns a cached timeline in one lookup, and a separate media pipeline (upload → object store → CDN).

Steps 6–7 — Detailed design & bottlenecks

Go deep where the interviewer pushes, and let the estimation keep guiding you: shard the tweet store (partition by ID to spread load; storing all of one user's data on one shard creates hotspots), decide the cache eviction and where to put it, and hunt single points of failure — replicate data and services so losing a few nodes degrades rather than downs the system. Add monitoring and alerting on the components the numbers flagged as hot (the read cache, the fan-out workers, the CDN origin).

Pitfalls (what makes an estimation worthless)

• Numbers with no decision attached. Reciting "1 billion reads/day" and moving on teaches the interviewer nothing. Every figure must end in "…therefore we do X."
• Forgetting peak vs average. Provisioning for the 11.6k/s average means falling over at the 23k/s peak. Always carry a peak multiplier.
• Ignoring media. Estimating text only (120 GB/day) and sizing one database for it misses the 8 TB/day of media that actually dominates cost and dictates the CDN + object-store split.
• False precision. 11,574 reads/s is not more correct than "~12k/s". Round aggressively; the goal is the order of magnitude that picks the architecture, not decimals.
• Unit slips. Mixing GB and GiB, or dropping a ÷86,400, is the classic way to be wrong by 1000×. Keep powers of ten explicit.

Selection & trade-offs: fan-out-on-write vs fan-out-on-read

The 2.5:1 read dominance plus read amplification (each read merges every followee) is the classic Twitter fork. The two named strategies:

• Fan-out-on-write (push). On each tweet, append its ID to every follower's cached timeline. Reads become an O(1) cache fetch. Use when reads ≫ writes and fan-out per user is bounded — which the estimate says is true for normal users. Cost: O(followers) work per write, and a "hot key" disaster for celebrities: one tweet by an account with 100M followers is 100M cache writes.
• Fan-out-on-read (pull). Store tweets once; assemble the timeline at read time by querying all followees. Use when writes are cheap and reads are rare, or for accounts with enormous follower counts where push is infeasible. Cost: every read pays the merge, punishing the very path the estimate showed is hottest.

What senior engineers actually pick: the hybrid. Push for ordinary users (cheap reads, bounded fan-out), pull for a small set of celebrities, and merge the two at read time for their followers. This is a direct consequence of the estimation: the read:write asymmetry justifies push in general, while the tail of the follower distribution forces the pull exception. The numbers didn't just suggest a design — they exposed exactly where a single strategy breaks.

Takeaways

• Estimation is the engine of the interview: users → QPS (peak & avg) → storage → bandwidth → cache, and each output forces a decision.
• A number without a "therefore" is wasted breath — always state the design choice it drives.
• Always separate peak from average, and always ask whether media (not text) dominates storage and bandwidth.
• The read:write ratio plus fan-out shape picks fan-out-on-write vs on-read; the real answer is usually the hybrid, and the estimate tells you where the boundary sits.

---

Sources: DesignGurus / Grokking the System Design Interview (the 7-step framework and the Twitter case study), Educative "System Design Interviews: A step-by-step guide", Alex Xu's ByteByteGo (back-of-envelope numbers and the fan-out trade-off), and Twitter's own engineering write-ups on timeline fan-out. Re-authored and deepened for this guide with airtight, decision-linked arithmetic.

I just read a lesson on **System Design Interviews  A step by step guide** (System Design) and want to truly understand it. Explain System Design Interviews  A step by step guide from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **System Design Interviews  A step by step guide** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **System Design Interviews  A step by step guide** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **System Design Interviews  A step by step guide** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.