Part I · Chapter 1 · The Diagram · lesson 1
Somebody drew six boxes and you nodded
12 min
Part I · Chapter 1 · The Diagram · lesson 1
12 min
Somebody stood at a whiteboard and drew six rectangles joined by arrows. They said "pretty standard setup" and moved on. Everyone nodded, including you.
Here is the drawing, written out:
a browser, pointing at a load balancer, pointing at two app servers, both of which point at a cache and at a database, and one of which also points at a queue that a worker reads from.
Nobody defined a single one of those words, because in that room everybody was assumed to know them already. This lesson is the definitions, and it does not give them as a glossary — it gives them by following one request through the picture and asking, at each box, what would break if the box were not there.
Start with the thing that makes the diagram smaller than it looks.
Predict
Server. A program that is running all the time, waiting to be asked something. It is not the metal box — the metal box is a computer, and a computer can run several servers at once. When somebody says "we added a server" they usually mean another computer; when they say "the server is down" they usually mean the program.
App server. The server that holds your code — the thing that knows what a profile page is. Everything else in the diagram is software somebody else wrote.
Load balancer. A server whose only job is to receive every request and hand it to one of the app servers behind it. It is the reason there can be two of them and the browser only needs to know one address.
Database. A server that remembers things after everything else has stopped, and that can be asked precise questions about what it remembers. It is the box in the drawing that it hurts most to lose.
Cache. A copy of an answer, kept somewhere faster, so the same question does not have to be answered twice. It is allowed to be out of date. That is not a flaw in a particular cache; it is what a cache is.
Queue and worker. A list of jobs, and a program that works through the list. Together they are how you say "this needs to happen, but not while somebody is waiting". Sending the welcome email is the classic one.
Notice what the definitions have in common. None of them is about technology, and all of them are about time: the load balancer decides where a request goes now, the cache trades freshness for speed, the queue moves work out of the moment somebody is waiting in. Almost everything in this subject turns out to be an argument about time or about what happens when two things arrive at once.
A beginner reads the boxes. The boxes are mostly interchangeable and mostly somebody else's software. The arrows are where the design is.
Each arrow is a claim that one thing may wait on another. That matters for two reasons you can use immediately, with no arithmetic at all.
An arrow is a way to be slow. If the app server has an arrow to the database, then a slow database is a slow page. If it has no arrow, it cannot be. When somebody says "the site is slow", the diagram gives you the complete list of suspects before you have measured anything.
An arrow is a way to be broken. If the app server cannot do its job without the database, then the database being down means the page is down. An arrow you cannot survive losing is called a dependency, and a surprising amount of this subject is the discovery that you have more of them than the drawing shows.
The arrow from the app server to the queue is the interesting one, because it is deliberately not that kind of arrow. The app server puts a job on the list and immediately replies to the user. If the worker is down, the welcome email is late and the sign-up still worked. Somebody chose that, and choosing it is the whole reason the queue is in the picture.
Check
Three questions. None of them needs you to know anything you have not just read, and all three are questions the person at the whiteboard should be able to answer in a sentence.
"Which of these can we lose without the site going down?" This sorts the boxes into the two kinds the diagram does not distinguish. If the answer is "none of them", you have learned that every box is load-bearing, which is a real and uncomfortable finding.
"What goes on the queue?" The answer tells you what the team has decided a user should not have to wait for. If nothing goes on the queue, the queue is in the drawing because the drawing is a habit.
"Why two app servers rather than one?" There are exactly two sensible answers and they are completely different from each other, which is lesson five. Whichever one you get, you will know something about the system that was not on the whiteboard.
None of these is a challenge to the design. They are the questions that turn a picture you nodded at into a picture you can read.
The condition under which this whole lesson stops applying: when the diagram is of a system that does not exist yet.
A drawing of a running system is evidence. You can ask what each box costs, what it is doing right now, and what happened last time it failed. A drawing of a proposed system is an argument, and the boxes are claims about a future that has not happened. Both get drawn with the same rectangles, on the same whiteboard, often by the same person in the same meeting.
The question that separates them is "is this running?" — and the honest follow-up for a proposal is "what are we expecting that makes this necessary?" That question is the entire next chapter.