The short version
Systems design is deciding how the pieces of a large software system fit together: where data lives, how services talk, and what happens when parts fail. It is the difference between code that works on your laptop and a product that survives a million users.
What it actually is
Every system answers the same few questions: where is state stored, who is allowed to change it, how do components communicate, and what breaks first under load. Databases, queues, caches, and load balancers are just recurring answers to those questions.
Why everyone asks about it
Interviews lean on systems design because it reveals judgment, not memorization. There is no single correct architecture; there are trade-offs, and the interviewer wants to hear you weigh them out loud: consistency against availability, latency against cost, simplicity against scale.
How to think about it
Start from the data and the failure modes, not the boxes and arrows. Ask what must never be lost, what can be stale, and what the system should do when a dependency disappears. The diagram falls out of those answers.
