What system design means
It is the set of choices, not the diagram.
Most people picture system design as boxes and arrows: a client, a server, a database. The picture is only a way of showing a design. The design itself is the set of choices behind it, and those choices are what a team argues about, builds and later has to live with.
Take a food-delivery app. Before drawing anything you must answer questions like: where do orders live? What happens if the restaurant never confirms? What happens when half the city orders dinner at 7pm on a rainy Friday? Each answer changes the picture. If orders must never be lost, the database needs a copy somewhere else. If confirmations can be slow, the order must wait in a queue instead of blocking the customer.
Those limits are constraints: how many users you expect, how much money you have, how big the team is, how soon you must ship, and what the law requires for the data you hold. A good design is not the fanciest one; it is the one that fits its constraints. A two-person startup and a company serving fifty million users can both have good designs, and the two designs will look very different.
It also helps to separate what is hard to change from what is easy. Swapping a button colour is cheap. Moving data from one kind of database to another after three years of growth is a project of months. System design is mostly about getting the hard-to-change decisions roughly right early, and keeping the rest flexible.
Your turn
Pick an app you used today. Write two questions its designers had to answer before drawing a single box.
Stuck? Think about where data lives and what happens when something fails.
What to remember
The boxes and arrows show a design; they are not the design.
Design means answering questions about data, failure and load.
Constraints decide what a good design is.
Get the hard-to-change decisions roughly right early.
Do not add parts you don't need yet.