Diagramming Conventions

A sketch becomes a diagram when every box and arrow carries meaning. Four conventions do most of the work.

How It Works

A system design diagram is only useful if someone else can understand it without your narration. Four conventions do most of the work: (1) boxes are components — services, data stores, caches — each labeled with what it IS and what it OWNS; (2) arrows are requests or data flows — always labeled with direction and type ("POST /orders", "publish OrderCreated event"); (3) group related components visually (client-side, edge, application tier, storage) to show the tier hierarchy; (4) mark external systems differently (dashed border, cloud icon) so readers know where trust boundaries sit. In interviews, label the arrows BEFORE adding more boxes — unlabeled arrows turn a diagram into a sketch, and evaluators read unlabeled arrows as vague thinking.

Real-World Example

The C4 model (Context, Container, Component, Code) from Simon Brown is the most widely-used convention for system architecture diagrams. Its core discipline: every level of abstraction gets its own diagram — don't mix "these are our services" with "this is how a request flows through one service," because the reader needs to know which level they're looking at. AWS reference architectures follow a related pattern with explicit icons for every service type, communicating intent at a glance without 20 lines of prose. Adopting ANY convention — C4, AWS-style, or your own — beats ad-hoc diagrams that need a paragraph of caption to understand.