The C4 Model: A Complete Guide to Architecture Diagrams
The C4 model is the most useful convention for architecture diagrams because it solves the one problem that ruins most of them: mixing abstraction levels. Here is how it works and how to apply it.
Simon Brown created the C4 model to bring order to architecture diagramming, which historically has been a free-for-all of inconsistent boxes and arrows. The core insight is borrowed from maps: you would never navigate a country using a single map that showed both national borders and individual house numbers. You use a set of maps at different zoom levels, each internally consistent. C4 applies that idea to software.
The name comes from its four levels of zoom: Context, Containers, Components, and Code. You do not always draw all four, and most teams live in the first two, but understanding the full ladder is what lets you choose the right rung for the reader in front of you. This guide explains each level, when to use it, and how to draw C4 diagrams cleanly in a tool like the dedicated C4 editor at /diagram-tools/c4-diagram.
Level 1: System Context
The context diagram is the highest zoom level and the one you should almost always draw first. It shows your system as a single box in the middle, surrounded by the people who use it and the external systems it talks to. That is it. No internal detail whatsoever. The audience is broad: product managers, new engineers, executives, anyone who needs to understand what the system is for and what it touches.
The value of a context diagram is that it defines the boundary. It answers "what is inside our responsibility and what is somebody else's" more clearly than paragraphs of prose. A good context diagram fits on one screen, has fewer than a dozen boxes, and could be explained to a non-technical stakeholder in two minutes. If yours is more complicated than that, you are probably leaking container-level detail into it.
Level 2: Containers
In C4, a "container" does not mean Docker. It means a separately deployable or runnable thing: a web application, a mobile app, an API service, a database, a message broker, a serverless function. The container diagram zooms into your system box from level one and shows these deployable units and how they communicate, including the protocols and technologies.
This is the workhorse level for engineering teams. It is detailed enough to reason about deployment, scaling, and failure, but abstract enough to fit the whole system on one page. When someone asks "how is this actually built," the container diagram is usually the right answer. Label each container with its technology (for example, "React SPA," "Go API," "PostgreSQL") and each arrow with how the communication happens (JSON over HTTPS, gRPC, async via a queue), because those labels are where the real reasoning happens.
Level 3 and 4: Components and Code
The component diagram zooms into a single container and shows its major internal building blocks - controllers, services, repositories, and the responsibilities each holds. It is useful when one container is complex enough that newcomers need help navigating it, but it is also the level where diagrams start to go stale fastest, because internal structure changes more often than deployment topology.
The code level (level 4) drops all the way down to classes and interfaces, and here C4's own guidance is refreshingly honest: you almost never need to draw it by hand. If you want that detail, your IDE and automated UML tools generate it more accurately than you can maintain manually. Most teams treat level 4 as "generate on demand, do not store." Reserve your hand-drawing energy for levels one and two, where human judgment about what matters is irreplaceable.
The building blocks of every C4 diagram
Across all levels, C4 uses a small, consistent vocabulary. Keeping to it is what makes a set of C4 diagrams feel coherent.
- Person: a human user or role that interacts with the system, drawn distinctly from software.
- Software System: the highest-level thing that delivers value; your system and the external ones it depends on.
- Container: a separately deployable application or data store, shown only at level two and below.
- Component: a grouping of related functionality inside a container, shown at level three.
- Relationship: a directed, labeled line describing who talks to whom and how, never left unlabeled.
- Technology annotation: the concrete tech on each container or relationship, which turns a vague box into an actionable one.
- Boundary: an optional dashed grouping to show the edge of your system or an enterprise, useful when several systems are in view.
How to draw C4 diagrams in practice
You can draw C4 with any general diagramming tool, but a tool that understands the model reduces friction. In Atlas Diagram Studio, the C4 tool at /diagram-tools/c4-diagram gives you the person, system, and container shapes as first-class elements, so you spend time thinking about the architecture rather than styling boxes. You can also describe your system to the AI generator at /diagram-tools/ai-diagram-generator and get a starting context or container diagram to refine.
A practical workflow is to keep a small set of living C4 diagrams - usually just context and one container view per system - stored where your engineers work and updated during design reviews. Because Atlas supports real-time collaboration and imports existing Mermaid and .drawio files, teams that already sketch architecture as text can migrate without redrawing. If you are comparing options, the notes at /diagram-tools/vs/lucidchart and /diagram-tools/vs/drawio cover how different tools handle structured architecture work.