What is system design?
Deciding how the parts of a product fit together, before anyone writes code.
When you write code, you decide how one program behaves. System design is one step above that. You decide how many programs there are, what job each one does, where the data is kept, and what happens when one of them breaks.
Start with the smallest example. You build a website. At the start it is one program on one computer. The data sits in a file next to it. This works fine for a while. Then two things happen. More people arrive than one computer can serve. And that computer needs a restart sometimes. So you say: "let us run two copies, and put the data somewhere both copies can reach." That is system design. Everything else in this app is the same move, done at a bigger size.
Most people expect system design to be about knowing more tools. It is not. It is about making a few decisions in the right order, and being able to say what each one costs you. A junior and a senior engineer often draw the same boxes. The senior one can explain why each box is there, and what they gave up to get it.
There is almost never one right answer. There are answers that match the requirements and answers that do not. Among the ones that match, some trade-offs you chose on purpose, and some you walked into by accident. Interviews look for the first kind.
What this site does differently. Most system design material is a catalogue: here is sharding, here is a message queue, here is how Instagram works. You finish it knowing more words and still freeze when someone says "design a ride-hailing app". The missing piece is rarely the components. It is the order you make decisions in, and the habit of saying what each one costs. So that is what this site drills.
The method: five stages, every time. (1) *Requirements*: ask what it must do and for whom, out loud, before drawing anything. (2) *Actors and lifecycle*: follow one request all the way through, including the times it fails. (3) *Numbers*: estimate the load, and find which part is hard. (4) *High-level design*: draw only boxes that a requirement or a number asked for. (5) *Deep dive and tradeoffs*: name the cost of each choice before the interviewer does. Stages 1 to 3 take about a third of your time and make everything after them defensible.
How to use this site. Every topic page and every problem asks you to write your own answer before it shows you ours. The gap between what you wrote and what you read is where the learning happens. Skipping it feels faster and teaches you very little. If you are stuck, take a hint: each one is a question to ask yourself, never the answer, and you can take every hint and still have to write your own.
Read the topics in order. The sequence is a dependency chain, not a list of subjects: caching before CDNs, replication before partitioning, transactions before distributed transactions. Each page assumes the ones before it and nothing after. Start at the top and it will feel like about fifteen ideas repeating at different sizes, which is close to the truth.
- It is about who does what and where data lives. It is not about knowing more tools.
- Every part you add has a price. Naming that price is the core skill.
- There is no single right answer. Only answers that fit, and costs you chose on purpose.
- The same few moves repeat at every size. You are learning about fifteen ideas, not a hundred.