What is system design? · System Design Course

What system design means, why it is a game of trade-offs, the few parts almost every system is built from, and how to use this course.

Writing a program that works on your laptop is one skill. Keeping a service working for millions of people, while data grows and machines fail, is another. System design is the second skill.

Crux: system design is choosing the parts of a software system and how they connect, so that it keeps working as users, data and failures grow. There is rarely one right answer, only trade-offs you can explain.

What it is

A system is everything that turns a user's click into a result: the clients, the servers, the databases, and the wires between them. System design is deciding which of those exist, what each one is responsible for, how they talk, and where the data lives.

System design is the zoomed-out view: boxes and arrows. Low level design zooms in on one box and decides its classes.

It helps to separate it from its neighbour. System design asks about boxes: do we need a cache, and where does the data live? Low level design asks about the code inside one box: which classes, which methods? This course is about the first. The second has its own course: Low Level Design.

Why it is hard

Nothing in system design is free. Every choice gives you one thing and costs you another.

Each pair is a trade-off. A design picks a point between the ends.

A cache makes reads fast, but it can show stale data.
Copies of data keep you running when a machine dies, but now the copies can disagree.
A queue absorbs a burst of traffic, but the user gets the answer later.

So a good design is not the one with the most parts. It is the one whose trade-offs fit the problem, and whose author can say why.

The same few parts, again and again

Open almost any large system and you find the same small set of parts. They appear in a predictable order, as the load forces them in.

A system grows by need. Each new box answers a specific problem.

A load balancer spreads requests across many servers, so no single server is the limit.
A cache keeps hot answers close, so the database is asked less often.
A queue accepts work now and lets workers finish it later.
Replicas are extra copies of the data, for safety and for more reads.

Each of these gets its own lesson later. For now, only remember the shape: start with one box, and add a part only when a real problem asks for it. Adding parts early is the most common way to make a design worse.

What the discussion is judged on

In an interview you get an open prompt such as "design a rate limiter", and nobody hands you a spec. That is on purpose. The interviewer is not checking whether you can recite an architecture. They are watching how you break an ambiguous problem down and reason about trade-offs.

Most rubrics reduce to these four. Notice that only one of them is about knowing things.

Navigate the problem. Ask what is needed, decide what matters most, and do not get stuck on a side detail.
Design the solution. Cover the core ideas, make it scale, and keep the structure clean. A tangled design is a failure mode, even if each part is correct.
Know the technology. Pick sensible tools and use realistic, current numbers, not outdated assumptions about hardware.
Communicate and collaborate. Explain your thinking, accept hints, and stay at the right level of detail.

What changes with experience is the depth, not the shape. A mid-level answer is expected to cover the basics well. A senior answer moves through the basics quickly and spends its time on the hard parts: the bottleneck, the failure, the trade-off nobody asked about. Many entry-level roles do not have this interview at all, and it matters more as the role gets more senior.

This course covers product and infrastructure design: things like a URL shortener, a news feed or a rate limiter. Designing the classes inside one component is Low Level Design.

What a good answer looks like

Whether it is an interview or a design review at work, strong designs follow the same path:

Ask first. Pin down what the system must do and how well, before drawing anything.
Get one path working end to end. A simple design that works beats a clever one that is unfinished.
Say the trade-off out loud. "I chose X because Y, and it costs Z."
Go deeper where it hurts. Find the bottleneck or the failure that matters most and work on that.
Use numbers only when they change a decision. Estimation is a tool, not a ritual.

The next lessons turn this path into a repeatable routine.

How this course is laid out

The course goes from a routine you can follow, to the ideas and tools behind every design, to full worked designs.

Introduction: this lesson, the six-step delivery framework, and how to estimate.
Core concepts: the ideas every design leans on, such as caching, sharding and the CAP theorem.
Key technologies: the real tools (databases, queues, gateways) and when to reach for each.
Common patterns: shapes that repeat, such as scaling reads or handling contention.
Breakdowns: full designs, from easy to hard.
Jargon and terminology: a revision section at the very end, with each keyword, its purpose and its typical values.

Read in order, and skip what you already know. If a word in a lesson is new, jump to the jargon section at the end, then come back.

Check yourself

Try these before moving on. The answers appear in the lessons ahead.

In one sentence, how does system design differ from low level design?
Give one trade-off that a cache introduces.
Why is it risky to start a design with ten boxes?
Name the four things a design discussion is judged on.