HomeGroundworkSystem Design

36 chapters · 3 levels · 0 exercises

System Design

Pick a level and you'll get these sections in the order that makes sense, from the request lifecycle to sharding, consensus and the tradeoff thinking the interview is actually scoring.

Start Pick your levelCompany questions
0 / 36 read0 exercises12 h 24 min left

Up next

The mental model

There is no answer key — the interviewer is scoring how you got there, not where you landed.

18 min read
Open this chapter

I've got

→ pick a run for tonight

Asked at big companies?

38 reported system design questions, each with a worked answer

From 20 companies, global and Indian, plus 66 coding questions. Cover the answer, run the clock, then compare.

Open company questions

Contents36 chapters

Every chapter, in reading order

Start at the top or jump to what you need. Tick a chapter once you have read it.

Beginner

0/7 read

Start with the client-server model and the handful of building blocks — load balancers, databases, caches, APIs — that every design question reuses.

  1. B1What system design interviews testThere is no answer key — the interviewer is scoring how you got there, not where you landed.18 min
  2. B2Client-server basicsA senior candidate can narrate everything between the keypress and the pixel — and knows what each hop costs in milliseconds.18 min
  3. B3Scaling: vertical vs horizontalBuy a bigger box or buy more boxes — and one modern box is far bigger than the candidate who instantly reaches for a cluster believes.16 min
  4. B4Databases in system designThe choice is decided by access pattern and consistency need — "SQL doesn't scale" is a claim that will cost you the interview.19 min
  5. B5Caching fundamentalsA cache is one bet placed at six distances — and the interesting number is never the hit rate, it's the miss rate.24 min
  6. B6APIs & communicationThe API is the coupling surface — every round trip, every version and every retry is a design decision someone will live with for years.22 min
  7. B7Walkthrough: a URL shortenerThe full 45-minute arc on the classic warm-up question — where every number is shown, every choice is defended, and the trap is the click counter.28 min

Intermediate

0/13 read

You know the building blocks. Now learn how they behave under real load: load balancing algorithms, CDNs, queues, and consistency tradeoffs.

  1. I1Load balancing in depthThe box everyone draws and nobody explains — where L7 earns its latency, why consistent hashing keeps recurring, and how a health check turns a brownout into an outage.22 min
  2. I2CDNsMove the bytes closer to the user — the cheapest 10x in system design, right up to the moment you cache something personal.23 min
  3. I3Message queues & async processingThe request path should only do the work the user is actually waiting for — everything else goes on a queue and gets retried.20 min
  4. I4Consistency modelsEvery consistency model is just a rule about which stale reads you are willing to let a user see.17 min
  5. I5ReplicationKeeping copies of the same data on several machines is easy until the machines disagree, and then every design choice is a decision about which copy you are willing to lose.26 min
  6. I6Rate limiting & throttlingThe only thing standing between one badly-behaved client and everybody else's latency.19 min
  7. I7Designing for availabilityAvailability multiplies down your dependency chain — five nines in one box is four nines in a system.19 min
  8. I8Storage systemsBlock, file, object — and why the bytes of a user upload should never touch your app servers.19 min
  9. I9Search systems (surface)The database scans; the inverted index looks up. Everything else in search is ranking and staleness.19 min
  10. I10Microservices and service discoveryWhen splitting a system pays for itself, what it costs, and how one service finds another once the addresses keep changing.14 min
  11. I11Security basics for designWho is calling, what may they do, and what happens on the day a secret leaks.13 min
  12. I12Walkthrough: a news feed / chat appFan-out on write, fan-out on read, and the hybrid that exists because one account has 150 million followers.23 min
  13. I13Walkthrough: a notification systemA notification system looks like a loop over users and a call to an API, until you remember that the APIs are other people's, the users can say no, and a retry can wake someone up twice.22 min

Advanced

0/16 read

The CAP theorem in depth, sharding at scale, distributed consensus, and the capacity math behind designing something like Twitter or Uber.

  1. A1The CAP theorem in depthYou never "pick two" — you pick one letter during a partition, and PACELC tells you what you picked for the other 99.9% of the time.19 min
  2. A2Transactions and isolationA transaction is a promise about what concurrent users can and cannot see, and the isolation level is how much of that promise you are actually buying.21 min
  3. A3Storage enginesEvery database is a bet about how data should sit on disk, and most of what surprises you in production (slow writes, slow deletes, bloat, compaction storms) follows from that bet.19 min
  4. A4Sharding & partitioning at scaleOne machine is a limit, not a bug — but the shard key you pick in week one is the decision you will still be paying for in year five.23 min
  5. A5Time, ordering and IDsMachines disagree about what time it is, so a distributed design has to decide what to trust: the wall clock, a counter that only counts causes, or a clock that admits its own error.22 min
  6. A6Distributed consensus (surface)Getting a group of unreliable machines to agree on one value — and why your job is to use a consensus system correctly, not to write one.19 min
  7. A7Batch & stream processingThe same computation can run over data that has ended or data that never will, and almost every hard question is about what time means and when you are allowed to call an answer final.30 min
  8. A8Designing for fault toleranceAt scale something is always broken — the design question is never "will it fail" but "what happens to everything else when it does".23 min
  9. A9Observability at scaleMetrics say something is wrong, traces say where, logs say what — and p99 says whether anyone noticed.19 min
  10. A10Release safety and incident responseMost outages follow a change. How to ship in small steps, watch the right signals, back out fast, and learn without blame.14 min
  11. A11Capacity estimationThe whiteboard arithmetic that turns hand-waving into a design — no calculator, about three minutes, out loud.17 min
  12. A12Real-world case studiesSix systems you use every week, one or two interesting decisions each, the bill that came with them, and what has changed since.23 min
  13. A13Walkthrough: a key-value storeA Dynamo-style store is not one clever idea but eight ordinary ones bolted together, and the interview is about the decision you make at each seam.25 min
  14. A14Walkthrough: a web crawlerA crawler is a loop that fetches pages and follows links, and every hard part is about not doing that too fast, too often, or forever.27 min
  15. A15Walkthrough: a payment systemPayments are the one design where the traffic is small and the hard part is never losing, inventing or doubling a cent, so the whole chapter is about proving what happened.24 min
  16. A16Tradeoff thinkingNobody is grading your architecture. They are grading whether you knew what you were giving up, and said so.18 min

Straight talk

Three honest notes

  • This curriculum leans on the other topics on this shelf on purpose — the databases chapter here assumes you already have SQL & Databases, the queues chapter assumes Node's message-queues chapter. System design is where they combine.

  • Every level ends in a walkthrough (URL shortener → news feed → real case studies) because tradeoff thinking is a conversation skill, not a fact you memorize.

  • Distributed consensus and chaos engineering are the deepest, rarest layer — most system design interviews never go there, but the advanced tier doesn't skip it.