C4 Model (Zoom Levels for Audiences)
Draw architecture as a few maps at different zoom levels — context, containers, components, code — and show each audience the level it needs.
To an executive
One crowded diagram confuses everyone. A short series of pictures, from the big picture down to the detail, lets each audience see what it needs and agree on it.
To an engineer
Draw architecture at four zoom levels: system context, containers, components and code. Name and type every element so diagrams from different teams line up.
The idea
Simon Brown created the C4 model to make architecture diagrams as easy to read as maps. Instead of one crowded picture, you draw a few, each at a different zoom level:
- System context — the system as one box, with the people and other systems it interacts with.
- Containers — the applications and data stores that make up the system, and how they communicate.
- Components — the main building blocks inside one container.
- Code — classes or tables, usually generated or left out.
Each level has a natural audience. A context diagram works for anyone, technical or not; deeper levels are for the people who build and run the system.
Why it works
One diagram cannot serve every audience. Executives drown in detail; developers find the overview too vague. Zoom levels give each the right map.
Shared abstractions beat shared notation. C4 cares less about shapes and colours than about agreeing what a "container" or "component" is, so diagrams from different teams line up.
It keeps diagrams honest. Every element needs a name, a type and a short description, and every line says what it carries.
Where it applies
- Onboarding and documentation, where people need to find their way around.
- Design reviews, to agree the scope before debating the internals.
- Stakeholder presentations, where the context diagram is often all you need.
How to apply
- Start with the context diagram — it is the one most people will see.
- Add a container diagram for anyone who builds, runs or secures the system.
- Draw component diagrams only where they help, usually for complex containers.
- Label everything and add a key; a diagram should make sense on its own.
- Keep diagrams close to the code (for example, as diagrams-as-code) so they stay current.
Example scenario
An architecture review kept getting stuck in database details before anyone agreed what the system did. The architect replaced the single wall-sized diagram with a context diagram and a container diagram.
The business sponsor confirmed the scope from the first in five minutes, spotting a missing partner system. The engineers then used the second for the technical discussion, and the review finished on time.
Questions to ask
- Who is this diagram for, and which zoom level do they need?
- Does every box and line have a label that says what it is and does?
- Could someone new understand the context diagram without me in the room?
When not to use it
- Dynamic behaviour or deployment questions, which need sequence or deployment diagrams; C4 itself suggests these as supplementary views.
How it misleads you
Drawing all four levels for every system creates documentation nobody maintains. The goal is the right picture for the audience, not complete coverage — most systems need two levels, kept up to date.
Further reading
Last reviewed · Suggest an improvement