Foundations
Learn the interview framework, requirements gathering, capacity estimation, and core trade-offs like CAP.
System design interviews, demystified.
A focused study guide on the building blocks, trade-offs, and patterns that come up in every system design interview.
Study the patterns that actually show up in interviews
Each topic is written as a self-contained study note so you can drill the concepts that matter most.
Networking
Understand load balancers, API gateways, CDNs, DNS, and the protocols that glue distributed systems together.
Data & Storage
Compare SQL and NoSQL, master indexing, replication, sharding, caching, and message queues.
Scale & Reliability
Reason about horizontal scaling, consistent hashing, rate limiting, fault tolerance, and observability.
A repeatable approach for any design question
Follow the same framework whether the prompt is a URL shortener, a chat app, or a global feed.
Browse the study tracks by category
Every page is short enough to read in a sitting and dense enough to power a whiteboard discussion.
Fundamentals
Networking & Delivery
Scalability & Reliability
Architecture Patterns
Common questions from candidates
A few of the things engineers ask before they walk into a design loop.
Getting Started
How to approach studying.
During the Interview
What interviewers actually look for.
After You Practice
How to keep improving.
Where should I start if I have never done a system design interview?
Read the Overview, then the Interview Framework. They cover the structure interviewers expect and what good and bad answers look like. From there work through Load Balancers, Caching, and SQL vs NoSQL — those concepts appear in almost every problem.
How long should I study before an interview?
Two to four weeks of focused study is enough for most candidates with backend experience. Spend the first week on Fundamentals, the next on Data & Storage and Networking, and the last on Scalability and practice problems.
Do I need to memorize numbers like latency and throughput?
You don't need to memorize a table, but you should be able to reason about orders of magnitude. The Back-of-the-Envelope Estimation page lists the numbers worth internalizing.
What do interviewers actually grade on?
Structured thinking, clear requirements, sensible trade-offs, and the ability to defend choices. They are not looking for a 'correct' diagram — they are looking for an engineer they would want on their team.
How much detail should I go into?
Start broad, then go deep where the interviewer asks. Move from requirements to API to data model to deep dives. The Interview Framework page walks through this in detail.
What if I do not know a specific technology?
Reason from first principles. Explain what properties you need (e.g., 'I need a durable append-only log with replay') and the interviewer will help you name the tool if they want to. Faking familiarity is always worse than reasoning honestly.
How do I get better at the deep-dive portion?
Pick a real system you use and try to rebuild it on paper. Compare your design to public engineering blog posts. The Architecture Patterns track is a good place to find vocabulary for those discussions.
Should I do mock interviews?
Yes — system design is a skill that gets dramatically better with reps. Use these notes as a vocabulary check before and after each mock.
Is this site free?
Yes. It's a study companion, not a course. All topics, diagrams, and notes are open.