What a system is

Start with a question that sounds too simple to ask: when someone says "the system is down", what exactly stopped working? Not the code, which is still sitting on disk. Not the machine, which may be humming along. What stopped was a promise. A system, for the purposes of this course, is a collection of parts that together keep a set of promises to the people who depend on them.

Promises, not boxes

A whiteboard drawing of boxes and arrows is a picture of a system, not the system. The boxes only matter because of what each one promises the others: this box answers within a hundred milliseconds, that box never loses a write it has acknowledged, the third one always returns the newest value it has seen. When you design, you are choosing which promises to make and deciding which part is responsible for keeping each one.

That framing does two useful things. It tells you what to test, because every promise implies a check. And it tells you what failure means, because a failure is a broken promise, whether or not anything crashed.

What counts as a part?

Anything that can fail on its own. A process is a part. A database is a part, and so is the disk underneath it. The network between two machines is a part, and it is the one most people forget until it fails. If two things always fail together, treat them as one part; if they can fail separately, treat them as two, because the interesting behaviour lives at the boundary.

Why "together" matters

A single program keeping a single promise is easy to reason about. The difficulty of system design is that promises are kept by several parts cooperating, and each part has its own idea of the current state of the world. Most of this course is about closing the gaps between those ideas cheaply enough to afford.

The three questions

Every design conversation in this course comes back to three questions.

Engineering note. If a proposal cannot answer all three questions in a sentence each, it is not yet a design. It is a wish.

A small example

Take a notes app with a single server and a single database. The app promises that a saved note is still there tomorrow. The server keeps that promise by handing the note to the database and waiting for confirmation; the database keeps it by writing to disk before confirming. Add a second server behind a load balancer and nothing about the promise changes, but a new gap opens: two servers can now hold different beliefs about whether a note was saved. You have not made the system faster yet. You have made it harder to keep the same promise.

That is the pattern to watch for throughout the course. Adding a part rarely adds a promise. It usually adds a place where an existing promise can be broken.

What to carry forward

• A system is defined by its promises, and a failure is a broken promise.
• Draw parts at the boundaries where things fail independently.
• Every added part needs a reason written in terms of a promise it helps keep.

The next lesson looks at what system design work actually looks like day to day, and why so little of it is drawing boxes.