Read the diagram back and say what each box is for

Here is the diagram from lesson one again, unchanged:

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.

In lesson one you nodded at it. This time you are going to take it apart.

The system is a tool used inside one company. Roughly two hundred people have accounts and perhaps thirty are using it at any moment during the working day. It stores records people type in, shows them back, and emails a weekly summary. It has been running for about two years and has never been down for longer than anyone minded.

Those sentences are the whole brief. Everything below is reading them against the picture.

Predict

Two hundred accounts, about thirty people using it at once, and a weekly summary email. Which box is doing the most to justify itself?

Choose one answer

The cache — thirty simultaneous users is a lot of repeated readsThe database — it is the only box that would lose data if it disappearedThe load balancer — without it, users could not reach either serverThe queue — the weekly email has to be sent somehow

Lock in answer

Box by box, against the brief

The database. Keeps the records. Without it, the data is gone. Justified at any size, and the one box nobody should be arguing about. Note that it appears once in the drawing — there is no second copy — which, given the two app servers, tells you something about what the team was worried about.

The two app servers. Lesson five said there are exactly two reasons. At thirty simultaneous users, capacity is not it; one modest machine serves that without noticing. So the reason is survival, and that is a legitimate choice for an internal tool people depend on during the working day. The giveaway is the single database beside them: a team that had bought survival properly would not have left the one box that matters undoubled.

The load balancer. Exists because the app servers are two. Its real job here is the health check — noticing when one server is broken and routing away from it. That is the mechanism actually delivering the survival the second server was bought for, and it is worth confirming that the check tests something real rather than returning the word "ok".

The cache. The hardest one to justify from the brief. Thirty people reading typed-in records is not a load any database struggles with. This is the box to ask about, and the question is lesson six's: what is the hit rate, and what happens when it is empty?

The queue and the worker. A weekly email. Something that happens once a week and that nobody is waiting on does not need a queue — it needs something that runs on a schedule. A queue is for work that arrives unpredictably and must not be lost.

Check

You suggest removing the cache. Someone replies that it was added because the records list page was slow. What is the right next move?

Choose one answer

Leave it — it was added for a reason and that reason still standsRemove it and see whether anyone complainsAsk why that page was slow, because a cache in front of a slow query leaves the slow query thereReplace it with a bigger cache so the hit rate improves

Check answer

The two I would remove, and what I would ask first

The queue and the worker, probably. A weekly email nobody is waiting on is a scheduled job. Removing the pair removes a running program, a piece of infrastructure, and a category of failure where a job sits unprocessed and nobody notices because nobody is waiting. The thing to confirm first is that nothing else is quietly using the queue — this is exactly the kind of box that acquires a second user nobody wrote down.

The cache, if the answer to the question above is a missing index. A cache covering a query that could be made fast is borrowed time with interest, and the interest falls due the day the cache restarts.

What I would add. A second copy of the database. The team clearly cares about survival — they bought a second app server and a load balancer for it — and they have left the one box whose loss is unrecoverable standing alone. That is the most common shape of mismatch between what a diagram says a team is worried about and what it actually protects.

None of these is certain from the brief, and that is the honest position. Each one is a question with a named thing to check, which is a different and much more useful output than an opinion about the architecture.

What chapter two does with this

Everything above was reasoning about shape. Not one number appeared, and the conclusions are correspondingly soft: probably, the hardest to justify, worth asking.

The next chapter does the same job with arithmetic, and the conclusions get hard. It opens with a drawing very like this one — three app servers, a managed database with a read replica, a cache, across two availability zones — and a product with five hundred users. It asks you to commit to a server count before anything is revealed. Then it divides users by seconds in a day, multiplies by a peak factor, and compares the result to what one machine actually serves.

The answer is one box, with a great deal of room left over. You can already see why that is the likely answer, which is the entire purpose of this chapter. What you cannot yet do is prove it to somebody who disagrees, and proof is what the arithmetic buys.

When the boxes cannot be removed

The condition under which this exercise is academic: when the system is already built and nobody is going to change it.

Removing a box from a running system costs a migration, a risk and somebody's week, and "this would be simpler without the queue" is not on its own worth any of those. The reading is still worth doing — knowing which boxes are load-bearing is exactly what you need at the moment something breaks — but the output becomes a list of things you understand rather than a plan.

The time this exercise pays fully is before the thing is built, when a box costs a sentence to remove. That is a meeting you will be in, and the question to bring to it is the one from lesson one: what would break without this?

Worth remembering

• Read a diagram by asking what would break without each box, not by what each box is called.
• At thirty simultaneous users, a second app server is bought for survival rather than capacity — and the single database beside it shows the survival argument was applied unevenly.
• A load balancer that exists because there are two servers is really there for the health check, which is what delivers the uptime.
• A cache in front of a slow query leaves the slow query in place, paid for by whoever misses and by everyone at once if it empties.
• Work that happens on a schedule and that nobody waits on does not need a queue; a queue is for unpredictable work that must not be lost.
• A box that is only needed because of another box can often be removed as a pair.
• Reasoning about shape yields soft conclusions; arithmetic is what turns 'probably overbuilt' into something you can prove to somebody who disagrees.