Stackbook Logo
← Back to Tracks

System Design Interview Preparation: A Guided Track

A six-week plan to prepare for system design interviews: a repeatable framework, core building blocks, estimation practice and mock exercises.

5 min read

System design interviews test how you reason about ambiguous problems, not whether you recall a particular architecture. Interviewers watch how you clarify requirements, estimate scale, choose components, and discuss trade-offs. Candidates fail more often from lack of structure and from not explaining their reasoning than from missing knowledge. This track gives you a framework, the building blocks, and a practice schedule.

Learning goals

  • Apply a repeatable framework to any open-ended design prompt.
  • Estimate load and storage quickly and sensibly.
  • Use core components, such as caches, queues and databases, and justify them.
  • Communicate trade-offs clearly under time pressure.

The framework

Use the same sequence each time. A typical 45-minute interview divides roughly as follows.

1. Clarify requirements and scope        (5 min)
2. Estimate scale                        (5 min)
3. Define API and data model             (5 min)
4. Draw high-level design                (10 min)
5. Deep dive on 1-2 hard parts           (15 min)
6. Bottlenecks, failures, trade-offs     (5 min)

Start by asking questions: who are the users, what are the core features, what is out of scope, what are the latency and availability expectations, and what is the read-to-write ratio? State your assumptions aloud. The interviewer expects you to drive.

Week 1: Fundamentals and estimation

Review latency orders of magnitude: memory access is nanoseconds to microseconds, SSD reads tens to hundreds of microseconds, a same-region network round trip about a millisecond, and a cross-continent round trip on the order of a hundred milliseconds. Precision is unnecessary; the ratios matter.

Practise estimation:

Photo app: 50M users, 10% upload daily, 2 MB per photo
Uploads/day  = 5M
Storage/day  = 5M x 2 MB = 10 TB
Per year     = about 3.6 PB (before replication)
Upload QPS   = 5M / 86,400 = about 60/s average, 200/s peak

Exercise: do five estimations from different domains and check that your units and powers of ten are consistent.

Week 2: Building blocks

Learn each component well enough to say when to use it and what it costs.

| Component | Use it for | Trade-off to mention | |---|---|---| | Load balancer | Spreading traffic, health checks | Single point of failure if not redundant | | Cache | Reducing read latency and DB load | Staleness, invalidation | | CDN | Static and media delivery | Cost, cache invalidation | | Message queue | Decoupling, buffering bursts | Ordering, duplicates, latency | | Relational DB | Transactions, flexible queries | Vertical scale limits | | NoSQL store | Horizontal scale, simple access patterns | Limited queries, weaker consistency | | Search index | Full text and filtering | Eventually consistent copy of data |

Exercise: write one paragraph per component explaining when you would not use it.

Week 3: Data, scaling and consistency

Practise partitioning (choice of shard key, hot keys), replication (leader-follower, lag), and consistency trade-offs. Be able to explain the CAP theorem accurately: during a network partition you choose between consistency and availability. Know consistent hashing, idempotency keys and at-least-once delivery.

Exercise: for a URL shortener, choose the ID generation approach, the storage model, and the cache strategy, then explain what happens when one shard fails.

Weeks 4 and 5: Classic problems

Work through problems, spending 45 minutes each, then review. Good set:

  • URL shortener
  • News feed or timeline
  • Chat system
  • Rate limiter
  • Notification service
  • File storage and sync
  • Ride matching or proximity search

For each, record the key insight: for a news feed, the fan-out on write versus fan-out on read trade-off; for a rate limiter, token bucket versus sliding window and where counters live; for a chat system, connection handling and message ordering per conversation.

Exercise: after each problem, write a short note listing what you forgot to ask, which numbers you got wrong, and which trade-off you did not mention.

Week 6: Mock interviews and communication

Do at least three mock interviews with a peer, ideally with feedback on communication.

Habits that score well:

  • Think aloud and structure: "I will first cover the happy path, then failure handling."
  • Propose a simple design first, then evolve it when requirements demand.
  • Offer two options for key decisions and justify your pick.
  • Quantify: "at 200 writes per second, a single database is fine."
  • Cover failure modes, monitoring and data consistency unprompted.
  • Say when you are unsure, and reason toward an answer.

Common mistakes

  • Jumping to microservices and exotic technology before establishing requirements.
  • Naming components without explaining why.
  • Ignoring failure and scale.
  • Going deep on a trivial part and never reaching the hard problem.
  • Memorising answers rather than practising reasoning.

Key takeaways

  • Use a fixed framework: clarify, estimate, define API and data, design, deep dive, review trade-offs.
  • Practise estimation until powers of ten are second nature.
  • Know each building block, including when not to use it.
  • Study classic problems for the insight behind them, not for the final diagram.
  • Practise aloud with mock interviews and review your communication.
  • Start simple, justify choices with numbers, and discuss failure modes without being asked.