Most architecture diagrams are optimistic. They show the happy path: a client talks to a service, the service talks to a database, arrows point in tidy directions. What they usually leave out is where the risk actually lives — which components hold sensitive data, where trust changes hands, which team is accountable for what, and where data quietly gets copied to a third place nobody remembers to secure.
That omission isn't cosmetic. As a system grows, the parts that get left off the diagram tend to be exactly the parts that cause incidents: the logging pipeline shipping PII to an analytics vendor, the cache holding session tokens, the "internal" service that's actually reachable from the internet. A diagram that hides those things doesn't just fail to help — it actively misleads the people making decisions from it.
This piece lays out a small set of principles for drawing system diagrams that make responsibility, data movement, and trust boundaries explicit, and then walks the same example system through three stages of growth so you can see how the risk surface expands as the architecture does.
What a component label should answer
Every box in a diagram represents a responsibility. If the label is vague, the accountability is vague too. A well-defined component should let a reader answer three questions without asking you:
