What system design means

Every app starts the same way: one program, one database, one user (you). It works. Then real people show up.

Suddenly there are ten thousand requests a second instead of one. The database table that held a hundred rows holds a billion. A server dies at 3 a.m. and nobody notices until customers complain. None of these problems are about whether your code is correct. They are about whether the system around your code holds up.

System design is the practice of deciding what parts a system has, what each part is responsible for, and how they talk to each other, so that the whole thing meets its requirements at the scale it actually runs.

The questions system design answers

When you design a system, you are answering a handful of questions again and again:

• Where does the data live? One database or many? Which kind? How is it split up?
• Who does the work? One server or a fleet? Does the work happen during the request, or later in the background?
• How do the parts communicate? Direct calls, a queue, a stream of events?
• What happens when something fails? A server crashes, a network link is slow, a disk fills up.
• How does it grow? What is the first thing that breaks at 10x traffic, and how do you fix it?

A system, drawn

Here is about the smallest real web system: a client, a server running your code, and a database.

Almost every design in this course is this picture, grown. You will add a load balancer when one server is not enough, a cache when the database is too slow, a queue when work does not need to finish during the request, replicas when one database cannot keep up. Each addition solves one problem and introduces new ones. Learning system design is mostly learning which problem each building block solves and what it costs you.

Design versus code

It helps to separate two kinds of decisions:

Both matter. But a beautifully written service that keeps all its state in memory on one machine will lose data the first time that machine restarts, no matter how good the code is.

There is no single right answer

Designs are not right or wrong in the abstract. They are right or wrong for a set of requirements. Caching aggressively is great for a news feed, where showing a post one second late harms nobody. It is dangerous for a bank balance. Running everything on one big machine is simple and cheap, and perfectly fine until the machine fails or the traffic outgrows it.

That is why the first step of every design, which you will learn in the next lesson, is finding out what the system actually needs.