Skip to content

🧭 System Design Prep

Personal, incrementally-built prep for FAANG Staff / Principal / EM system-design interviews. The goal is not to memorize architectures — it's to derive them from requirements, recognize reusable patterns, reason about trade-offs, find bottlenecks, and defend decisions like a Staff Engineer.

Built with MkDocs Material — use the top tabs, the left sidebar, or press / to search.

How to use this repo

Every system is worked through the same 20-step framework so the method becomes muscle memory. For each topic the loop is:

teach the concept → simplest architecture → increase scale → challenge the design → answer follow-ups → critique → capture lessons

Always start simple. No Kafka / Kubernetes / Cassandra / sharding / microservices until a requirement forces it — and every added component must answer "why do we need this, and what does it solve that the simpler design can't?"

Design as a staircase of "stops" — never be blind

Every system is presented as a staircase: the smallest defensible design first, then each bigger stop with the exact trigger (bottleneck/SLA) that forces it. Lead with the simple stop; know the big one. Each system's ★ Principal Deep Dive is the "never be blind" companion — the fully-loaded, max-scale (deliberately over-engineered) variant with a reconciliation table mapping every heavy component to the trigger that justifies it and when it's overkill and should be removed. Goal: competent at small, fluent about big, disciplined about the difference.

Repository map

Section What's in it Status
00-framework/ The 20-step method, capacity math, staff-level thinking, interview wording, checklist 🟢 done
01-patterns/ Caching 🟢 · Sharding 🟢 · Queues & Workers 🟢 · Idempotency 🟢 · Rate Limiting 🟢 · realtime, object storage, observability, multi-region (planned) 🟢 building
02-systems/ URL Shortener 🟢 · Web Crawler 🟢 · Job Scheduler 🟢 · Notification System 🟢 · chat, file storage, YouTube, rate limiter, metrics, news feed, payments, ride-sharing (planned) 🟢 building
03-tradeoffs/ SQL vs NoSQL, Kafka vs SQS, sync vs async, push vs pull, WebSocket vs SSE, active-active vs active-passive ⚪ planned
04-interview-drills/ Bottleneck drills, failure scenarios, scalability & DB questions, staff-level follow-ups ⚪ planned
05-cheatsheets/ 1–2 page revision sheets ⚪ planned
06-mocks/ Timed mock interviews ⚪ planned

Progress

Building one topic at a time (per the learning plan in prompt.txt):

  • [x] 00 · Framework — the lens every design uses
  • [x] 02 · URL Shortener — first full per-system walkthrough
  • [x] 01 · Caching pattern — the highest-leverage read-scaling move
  • [x] 01 · Partitioning & Sharding pattern — the write/storage-scaling last resort
  • [x] 01 · Queues & Workers pattern — async processing foundation
  • [x] 01 · Idempotency pattern — what makes retries safe
  • [x] 02 · Web Crawler — assembles queue+workers, idempotency, sharding, caching
  • [x] 01 · Rate Limiting pattern — token/leaky bucket, windows, distributed Redis limiter
  • [x] 02 · Distributed Job Scheduler — scheduling, exactly-once effect, leases + fencing
  • [x] 02 · Notification System — fan-out, multi-channel, provider resilience, preferences
  • [ ] 01 · More patterns (realtime, observability, object storage…)
  • [ ] 02 · More systems (URL Shortener done; chat, file storage, YouTube…)
  • [ ] 02 · Chat / Messaging
  • [ ] 02 · File Storage (Dropbox)
  • [ ] 02 · YouTube / Video
  • [ ] 02 · Rate Limiter
  • [ ] 02 · Metrics / Observability Platform
  • [ ] 02 · News Feed
  • [ ] 02 · Payment System
  • [ ] 02 · Ride Sharing

Start here

  1. The 20-step framework — the backbone of every answer
  2. Capacity estimation — the only math you need, and which numbers matter
  3. Staff-level thinking — the questions that separate senior from staff
  4. Interview wording — phrases that sound clear and experienced
  5. Interview checklist — the fast pre-interview scan

Built with Claude Code · rendered with MkDocs Material · this is a living document — notes get sharper after every mock.