About System Design Study

Why this site exists

System design interviews are notoriously open-ended. There is no single “correct” answer, the prompts span everything from databases to networking to architecture, and the bar shifts depending on the company and level. Most candidates end up reading scattered blog posts, watching long videos, and still arriving at the whiteboard unsure of how to actually structure their thinking.

System Design Study is a focused, opinionated study companion. It is written for software engineers who already know how to build software and want a tight, repeatable mental model for the design loop.

What you will find here

Every page on this site is a self-contained study note. Each one is short enough to read in one sitting and dense enough to power a real whiteboard discussion. Pages are grouped into five tracks:

• Fundamentals — the interview framework itself, how to gather requirements, how to estimate scale, and the core trade-offs (CAP, consistency, latency vs throughput) you’ll be expected to reason about.
• Networking & Delivery — DNS, load balancers, API gateways, CDNs, and the application-layer protocols that connect distributed systems.
• Data & Storage — SQL vs NoSQL, indexing, replication, sharding, caching, and message queues.
• Scalability & Reliability — scaling strategies, consistent hashing, rate limiting, fault tolerance, and observability.
• Architecture Patterns — monolith vs microservices, event-driven architecture, and how to pick the right shape for a problem.

How to use it

If you are starting from scratch, read the Overview and Interview Framework in Fundamentals first, then work topic by topic through the sidebar. If you have an interview in a few days, skim every page once and re-read the deep-dive sections on whichever topics feel weakest.

Pair the reading with mock interviews. Notes alone won’t teach you how to manage time, drive a conversation, or defend a design under pressure — only reps will. This site exists to make sure that when an interviewer asks “how would you scale this?”, you already have the vocabulary and the trade-offs at your fingertips.

A note on opinions

System design is full of decisions with no universally right answer. Where reasonable engineers disagree, this site picks an opinion and explains why, rather than listing every possible option without commentary. The goal is to give you a defensible mental model — not an exhaustive encyclopedia.

If you spot something wrong, outdated, or unclear, please open an issue or pull request. This site improves through the same feedback loop as good systems do.