System Design Interview Preparation

System design interviews test whether you can think about real products β€” not whether you can design Twitter for 1 billion users on day one.

For student and junior roles, interviewers want:

  • Clear requirements gathering
  • A sensible high-level diagram
  • Knowledge of common building blocks (API, DB, cache, CDN)
  • Honest tradeoffs (β€œI’d start simple, then scale X if needed”)

What Interviewers Look For

  • You ask clarifying questions before jumping to solutions
  • You explain why you chose each component
  • You mention scalability, but at a realistic student-project level
  • You connect concepts to something you’ve actually built

Files in This Section

FilePurpose
fundamentals.mdScalability, availability, latency, CAP, load balancing, caching, CDN
frontend-system-design.mdComponent architecture, state, performance, infinite scroll, autocomplete
backend-system-design.mdAPI design, auth, database choices, caching layer
design-a-social-media-app.mdFull walkthrough: feed, posts, likes, media
design-a-chat-app.mdFull walkthrough with WebSockets
design-a-url-shortener.mdFull walkthrough: encoding, redirects, analytics
interview-questions.md30+ questions with full answers
revision-sheet.mdOne-page cram before interview
mock-interview.md45-minute practice flow

Study Order

  1. fundamentals.md β€” vocabulary you’ll use in every answer
  2. frontend-system-design.md + backend-system-design.md β€” split by your role focus
  3. One full design walkthrough (url-shortener is easiest, then chat, then social-media)
  4. interview-questions.md β€” 5 questions/day, out loud
  5. mock-interview.md β€” practice with a friend on a whiteboard
  6. revision-sheet.md β€” night before interview

Time Estimate

  • Minimum viable prep: 3–4 days (fundamentals + one design + 15 questions)
  • Solid prep: 1–2 weeks (all designs + mock interview)

How to Answer Any Design Question

Use this framework (say it out loud):

  1. Clarify β€” users, scale, features in/out of scope (2–3 min)
  2. Estimate β€” rough numbers (users, QPS, storage) (2 min)
  3. High-level design β€” draw boxes: client β†’ API β†’ DB β†’ cache (5 min)
  4. Deep dive β€” pick 1–2 areas the interviewer cares about (15 min)
  5. Tradeoffs β€” what you’d do differently at 10x scale (5 min)

Project Connection

Every design answer gets stronger when you say: β€œIn my project, I did something similar when…”

Be ready to explain what breaks first if 1,000 users hit your capstone at once.

Interactive

Load Balancer Algorithms

Crank the traffic, slow one server down, and watch round-robin drown it while least-connections routes around β€” the difference explained in one animation.

algorithm
server 2 is slow (3Γ—)

2.0s of traffic, routed by round-robin: 6 requests so far.

client Aclient Bclient CLBserver 1server 2server 3
server 1: handled 2 Β· queued 0server 2: handled 1 Β· queued 0server 3: handled 1 Β· queued 0
1 / 4

Cache Flow Simulator

Follow every request through Browser β†’ CDN β†’ Redis β†’ DB, tune the TTL, then unleash a thundering herd and watch the database take the hit.

thundering herd

Cold start: the first request found every cache empty and pierced to the DB (DB queries so far: 1).

BrowserCDNRedisDB Β· 1
hits β€” browser 0 Β· CDN 0 Β· Redis 0DB queries 1total 1
1 / 4

WebSocket + Redis Pub/Sub

Send a message from a client on server 1 and watch clients on server 2 miss it β€” then switch on the Redis bus and see the fan-out fix scaling.

Redis pub/sub bus

Client A (on server 1) sends a message.

A Β· 0B Β· 0C Β· 0D Β· 0server 1Redis busserver 2
received β€” A: 0 Β· B: 0 Β· C: 0 Β· D: 0missed deliveries 0
1 / 4

CAP Theorem: Cut the Wire

Partition two replicas, choose consistency or availability, and watch your bank balance lie β€” or your writes bounce. CAP stops being abstract.

network
system chooses
scenario

Write lands on A (β‚Ή100); replication is on the wire to B (still β‚Ή0).

Node A Β· β‚Ή100Node B Β· β‚Ή0
A β‚Ή100B β‚Ή0rejected 0
A: write βœ“ β‚Ή100 β€” replicating to B
1 / 3

Study materials