Zoom In, Zoom Out
At the architecture level the store is Frontend → Backend → Database. Zoom into Backend and it is Router → Service → Repository; zoom into Database and it is Planner → Index → Pages. Every box is a system at the next zoom, and choosing the zoom is choosing which questions are visible.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
At which zoom level does this question have an answer — and what does each box become when you zoom into it?
The architecture diagram has three boxes and it answers nothing I am asked. "Where does validation happen?" is somewhere inside Backend. "Why does this query read so much?" is somewhere inside Database. I keep being told to "look at the architecture" and the architecture has no inside.
Make the diagram bigger. Add every component — router, services, repositories, planner, indexes, cache, queue — to the one diagram, so that every question has a box. It is thorough and it will be the reference.
The one diagram now has forty boxes and is read by nobody, including its author. The three-box version answered "what talks to what"; the forty-box version answers that too, illegibly, and answers "where does validation happen?" only if you already know.
- The one diagram now has forty boxes and is read by nobody, including its author. The three-box version answered "what talks to what"; the forty-box version answers that too, illegibly, and answers "where does validation happen?" only if you already know.
- Levels are mixed on one sheet: an SSD next to a React component, connected by an arrow that means nothing. A diagram where every box is at a different zoom cannot say which questions belong to which box.
- Because there is one diagram, there is one conversation. The product manager asking about checkout and the engineer asking about page reads are shown the same picture and both leave with less than they came with.
- The diagram is the deliverable, so drawing it feels like understanding the system. Nothing in it has been zoomed into on purpose, so the understanding is of the sheet, not of the boxes.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Treat every box as a system at the next zoom. Frontend → Backend → Database is true and useful at the zoom where the question is "what talks to what over the network". Backend, zoomed, is Router → Service → Repository, and the question that becomes visible is "which layer decides?". Database, zoomed, is Planner → Index → Pages, and the question is "how does a query become page reads?".
- Match the zoom to the question. "Where does validation happen?" is answered at the Backend zoom, in the layer between Router and Service. "Why so many reads?" is answered at the Database zoom, between Planner and Index. "Which component calls the payment provider?" is answered at the architecture zoom. Asking a question at the wrong zoom yields "somewhere in there".
- Zoom in from a box, not from nowhere. The Database zoom is entered from the Database box of the architecture diagram, carrying the question that sent you: "the checkout query". Zooming in without a question produces a diagram of everything inside, which is the forty-box sheet again, one level down.
- Zoom out to check the answer against the neighbours. A validation layer found inside Backend has to agree with what the Frontend already validates and what the Database constrains; the answer at one zoom is checked at the zoom above, where the boxes it touches are visible (Decomposition by Layer).
Three zooms of the store
The diagram shows the architecture zoom and, beneath two of its boxes, the next zoom in. Each inner row has its own vocabulary and answers its own questions; the arrows between zooms mean "this box, opened". Nothing from the inner rows appears on the outer one.
Which zoom answers which question
The matrix is the working tool: a question, the zoom that answers it, and the box to enter carrying it. Reading down the middle column shows why the forty-box diagram fails — the questions live at three different zooms, and one sheet can only be at one.
| Question | Zoom | Enter from | Answer lives between | Domain |
|---|---|---|---|---|
| Which component talks to the payment provider? | architecture | — | Backend and the outside | this domain; Backend |
| Where does validation happen? | Backend | the Backend box | Router and Service | Backend: layering |
| Which layer enforces "never oversell"? | Backend, then Database | the Service | Service and the transaction | Design: invariants; Database |
| Why does the checkout query read so much? | Database | the Database box, carrying the query | Planner and Index | Database: indexes |
| Why is the cart total different in two tabs? | Frontend, then architecture | the Frontend box | client state and its owner | Frontend: state; Who Owns This State? |
Zooming into the checkout query
A zoom-in, done as a decomposition: the Database box opened with one question carried in, and each leaf an observation you could make. The tree is deliberately about one query. A tree about "the database" would be the forty-box sheet.
- ├Planner— it chooses how the rows are found
- └Which plan was chosen?testable EXPLAIN shows a sequential scan or an index lookup for this exact query with production-like data.
- └Why that plan?testable With an index on the filtered column present, the plan changes; without it, the scan is the only option.
- ├Index— the structure that would make the lookup cheap
- └Does an index cover the filter?testable The catalogue lists an index whose leading column is the one the query filters on.
- ├Pages— what actually gets read
- └How many pages, and from where?testable The query's buffer statistics show pages read, and whether from the buffer pool or from disk.
- ├Zoom out: is it the right query?— the answer at this zoom has a neighbour above
- └Does the Service filter on the right column?testable Reading the Repository call shows the filter column the Service chose, and it matches what checkout needs.
How to do it
Most important first.
- Keep the three-box architecture diagram, and keep it at three boxes. It is the map for the zoom, not the territory.
- For each box, draw its inside as its own diagram with its own vocabulary: Backend as layers, Database as the query path, Frontend as components and state. Each fits on a screen because each is one zoom.
- When a question arrives, name its zoom before answering. If the answer is "somewhere inside X", zoom into X carrying the question.
- After answering at a zoom, step out one level and check the neighbours the answer touches (Interfaces Emerge From Boundaries).
- Use the zoom lab for the checkout path: each level links to the domain that teaches it, which is where the vocabulary for that zoom lives.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- "Where does validation happen?" At the architecture zoom: somewhere in Backend, and also somewhere in Frontend and Database, which is the useful observation — three places, so three different validations. Zoom into Backend: Router parses and rejects malformed input; a validation layer between Router and Service checks shape; the Service checks business rules (stock, price); the Repository trusts what it is given. Zoom out: the Frontend validates for feedback, not for safety; the Database constrains as the last line. The question has a layered answer once the zooms are separated.
- "Why does the checkout query read so much?" Architecture zoom: the Backend calls the Database once for checkout — nothing to see. Zoom into Database carrying "the checkout query": Planner chooses a scan because there is no index on the column the query filters; Index would have found the rows in a few reads; Pages are read in full instead. Answer at this zoom: an index on that column. Zoom out to check: the Repository builds that query, and it filters on a column the Service chose — is that the right column? Sometimes the fix is one zoom up.
- "Which component talks to the payment provider?" Architecture zoom: the Backend, and only the Backend — the Frontend must not, the Database cannot. That answer is complete at this zoom; zooming into Backend to find the specific service is a different question, asked when someone needs to change it (Inside and Outside the System).
How you know it worked
What now exists that did not before, and what question you can now ask.
- There are several diagrams, one per zoom, and each fits on a screen and uses one vocabulary.
- Questions get a zoom before an answer, and "somewhere in there" has become "zoom into X, carrying this question".
- Answers found at a zoom are checked against the neighbours one level out, and occasionally moved there.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?At which zoom does this question have an answer that is not "somewhere in there"?
- ?What is inside this box at the next zoom, and what is its vocabulary?
- ?Which question am I carrying into this zoom — and if none, why am I zooming?
- ?Does the answer I found at this zoom agree with the neighbours one level out?
What can go wrong
- Zooming in without a question. Every box is expanded to its inside for completeness, and the result is the forty-box diagram distributed across seven sheets.
- Never zooming out. The index is added at the Database zoom and nobody checks that the Service is filtering on the right column; the answer was correct for the wrong question.
- Confusing zoom with importance. The Database zoom is not "lower level engineering" than the architecture zoom; it is a different set of questions, and someone has to be able to ask them.
- Zooming into the wrong box. "Why is search slow?" sends the engineer into Database because that is where slow things live, and the response-size problem was at the architecture zoom, between Backend and Frontend (Highest Useful Level First).
- Several diagrams are more to maintain than one, and the zooms drift apart as the system changes; the architecture diagram tends to survive and the inner ones tend to rot.
- Answering a question at its zoom requires the vocabulary of that zoom, which is a domain to learn; the zoom lab links each level to its domain because this lesson cannot teach them.
- Zooming out to check the neighbours is a step that finds nothing most of the time, and is skipped for that reason until the time it would have found the Service filtering on the wrong column.
- "The architecture diagram is too simple; it needs more boxes." It is exactly as simple as its zoom, and its zoom is what makes it useful. The missing boxes belong to the next zoom, on their own sheet.
- "Zooming in is what senior engineers do." Senior engineers zoom in *and out*, and they zoom in carrying a question. Depth without a question is a tour.
- "Each zoom is a different team's problem." Zooms are levels of one system, and the answer to a question often lives at the boundary between two of them. A team per zoom is one way to organise; it is not what the zoom means.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALEvery system has zooms — a chat app's Realtime box is Connection → Fan-out → Delivery inside, an ML service's Model box is Tokeniser → Forward pass → Sampling. The move is the same: match the zoom to the question and carry the question in.
- SIMPLIFIEDThree zooms with three boxes each is a teaching shape. Real systems have more boxes per zoom and more zooms, and some boxes (a cache, a queue) appear at several zooms with different meanings; the discipline of one vocabulary per sheet is what survives the extra detail.
- ILLUSTRATIVEThe three questions and their answers are invented for a small store; where validation lives and why a query scans are decisions and facts that differ per system.
Where the depth lives
This domain asks the question and hands the answer off by name.