Most people don't fail a system design interview because they don't know the technology. They fail because they have no method. They hear "Design Twitter," jump straight to "let's use a database," design one random corner in great detail, ignore the rest, and run out of time with a half-drawn box on the whiteboard. The candidates who pass aren't smarter — they follow a repeatable sequence, out loud, every single time.
This is the condensed framework; the full guide (every step in depth, the building blocks, the numbers to memorize, and a full worked example) is on my site 👇
Full guide: https://prepstack.co.in/blog/how-to-crack-system-design-interview-framework
Why the question is open-ended on purpose
"Design Twitter" has no single right answer, the scope is huge, and you have 45 minutes. That's the point — the interviewer isn't checking whether you memorized Twitter's architecture. They're watching how you navigate ambiguity, make trade-offs, and communicate. Give them a clear, structured walk through the problem and you pass, even if the final design isn't "perfect."
The framework at a glance
| Step | What you do | Time (~45m) |
|---|---|---|
| 1 | Clarify requirements (functional + non-functional) and scope down | ~5 min |
| 2 | Back-of-envelope estimates (QPS, storage, bandwidth) | ~5 min |
| 3 | API design — the handful of endpoints that matter | ~5 min |
| 4 | Data model — entities, SQL vs NoSQL and why | ~5 min |
| 5 | High-level architecture — draw the boxes | ~10 min |
| 6 | Deep-dive the hard part — the 1–2 interesting things | ~10 min |
| 7 | Bottlenecks & scaling — cache, shard, replicate, queue | ~5 min |
| 8 | Trade-offs & wrap-up | ~3 min |
The steps that actually decide pass/fail
1. Clarify + scope down. Never start designing — start asking. Functional (what it does) + non-functional (scale, latency, consistency, read:write ratio). Then cut ruthlessly to 2–4 features and park the rest out loud. The single most common failure is skipping this and designing the wrong system beautifully.
2. Estimate. You're after order of magnitude, not precision. The shortcut: there are ~86,400 s/day ≈ 10^5, so requests/day ÷ 100,000 ≈ average QPS, and peak ≈ 2–3×.
1,000,000,000 reads/day ÷ 86,400 ≈ 11,600 QPS average
Peak ≈ 3x ≈ ~35,000 QPS
That one number already tells you: no single DB serves this — you need caching, replicas, sharding.
3–4. API + data model. Define the contract first (cursor-based pagination, not offset; explicit auth). Then pick a store and justify it — "tweets are append-heavy, read by key, no joins, so a wide-column store scales better than relational here." The reasoning is graded, not the choice.
5. Draw the architecture. Client → load balancer → stateless app servers → cache/DB → response. Push heavy/slow work (media, notifications, fan-out) onto a queue + workers so the request path stays fast.
6. Deep-dive the ONE hard part. Every "Design X" has 1–2 things that make it interesting; the rest is plumbing:
| Problem | The hard part |
|---|---|
| URL shortener | Short-code generation & collisions |
| Rate limiter | The algorithm + distributed counters |
| News feed | Fan-out on write vs read (celebrity problem) |
| Chat | Real-time delivery, ordering, presence |
| Uber | Geospatial indexing & matching |
| Payments | Idempotency & the ledger |
| YouTube | Transcoding pipeline & CDN |
One well-reasoned deep-dive beats ten shallow boxes.
7–8. Bottlenecks + trade-offs. Ask "what breaks first?" → caching (name the invalidation), read replicas, sharding (state the shard key), async queues, CDN, remove single points of failure. Then close by naming the trade-offs you made and what you'd revisit. Raising bottlenecks before the interviewer does is a senior signal.
The ~10 building blocks every problem reuses
Load balancer · cache (Redis) · CDN · database (SQL for consistency, NoSQL for scale; replicas for read scale, sharding for write scale) · message queue (Kafka/SQS) · blob store (S3 — never put video in your DB) · consistent hashing · rate limiter / API gateway. Learn these cold and every "Design X" becomes an assembly problem.
The numbers to memorize
- Latency: RAM ~100 ns, SSD random read ~100 µs, same-DC round trip ~500 µs, HDD seek ~10 ms, cross-continent round trip ~150 ms. Memory is fast, disk is slow, network is slower the farther it goes — so cache aggressively and keep data near users.
- Powers of two: 2^10 ≈ 1 KB, 2^20 ≈ 1 MB, 2^30 ≈ 1 GB, 2^40 ≈ 1 TB.
- Availability: 99.9% ≈ 8.7 h down/year · 99.99% ≈ 52 min · 99.999% ≈ 5 min. Each nine is ~10× harder — ask how many you actually need.
The mental model
A system design interview is a guided conversation about trade-offs, not a test with an answer key. The interviewer is your collaborator, not your examiner. Three habits separate a pass from a fail: clarify and scope before you design, let numbers drive decisions, and communicate relentlessly (no silent whiteboarding). Master the 8 steps, the 10 building blocks, and the handful of numbers, and "Design X" becomes the same well-worn walk applied to a new destination.
The full guide has every step in depth, the 45-minute timeline, the full building-blocks diagram, the complete latency/powers-of-two/QPS tables, a full "Design Pastebin" worked example in one lap, and the where-the-framework-bends honest section:
https://prepstack.co.in/blog/how-to-crack-system-design-interview-framework
Originally published on PrepStack.
Top comments (0)