Three diagrams that pay rent.
The architecture, sequence, and topology drawings I redraw on every engagement. Templates included.
I redraw the same three diagrams on every engagement. After 7+ years of this, I’ve stopped trying to be original.
If you’re walking into a new system, draw these in this order. They unlock different conversations.
1. The architecture diagram
Boxes for services, lines for the dependencies between them. That’s it.
Constraints I impose:
- One page. If it doesn’t fit, your boundaries are wrong.
- No protocols on the lines unless they’re surprising.
- One color per “trust zone” — what crosses a network boundary, what stays inside.
This diagram exists to answer: what runs where, and what talks to what?
2. The sequence diagram
Time on the vertical axis, services on the horizontal. Pick the most important user-facing flow and draw it end-to-end.
Constraints:
- Start from the user action, not from the API gateway.
- Include the failure paths — what happens when call 3 of 7 times out?
- Annotate the latency budget on each arrow if you can.
This diagram exists to answer: where does latency and failure come from in the critical path?
3. The topology diagram
Where the data lives and how it moves between stores. Not the same as the architecture diagram — services are an implementation detail of some of the data movement, not all of it.
Constraints:
- Stores get boxes, services don’t appear unless they own a store.
- Arrows are flows of data, labeled with the trigger (event, batch, request).
- Mark which stores are sources of truth and which are derived.
This diagram exists to answer: if this store is wrong, what is also wrong?
Why three
Architecture answers “what.” Sequence answers “when, in what order.” Topology answers “where the truth lives.” Most production conversations turn out to be one of those three questions, badly disguised.
If a meeting is stuck, draw whichever of these the room hasn’t seen yet. Half the time the disagreement collapses inside ten minutes.