C4 Model

The C4 Model is a framework for diagramming software architecture at four levels of abstraction: Context, Container, Component, and Code. Created by software architect Simon Brown, it addresses a common problem with architecture diagrams: a single diagram either tries to show everything (and becomes unreadable) or shows one narrow slice (and loses the bigger picture). The C4 Model solves this by producing a set of related diagrams, each zoomed to a different level of detail, similar to how a map app lets you zoom from a country view down to a street view.

The Four Levels

1. Context: The highest-level view of your system as a single box, showing how it interacts with users and other external systems. Aimed at both technical and non-technical audiences.
2. Container: Zooms into the system to show its major deployable pieces: applications, services, databases, and how they communicate. A container here is any separately runnable unit, not just a Docker container.
3. Component: Zooms into a single container to show its major structural building blocks and their responsibilities and interactions.
4. Code: The most detailed level, showing classes, interfaces, or database schemas typically generated automatically from code rather than drawn by hand, and often skipped in day-to-day documentation.

Why Teams Use the C4 Model

Most architecture diagrams age poorly because they're drawn once, at one arbitrary level of detail, and never map cleanly to the questions different audiences actually ask. A new engineer wants Context and Container; a team lead debugging a specific service wants Component; a compliance reviewer wants Context. By deliberately separating levels, C4 diagrams stay legible and are easier to keep in sync with an evolving system than a single sprawling architecture diagram trying to serve every audience at once.

How to Create C4 Diagrams

1. Start with Context: get the big picture agreed on before drilling into any one system.
2. Draw Container next for systems that need more detail, showing the major runtime pieces and how they talk to each other.
3. Only go to Component level for complex containers that actually need the extra detail; not every container warrants one.
4. Keep notation consistent across diagrams (shapes, colors, relationship arrows) so viewers can move between levels without relearning the visual language.
5. Version and update diagrams as the architecture changes, since a stale C4 diagram is worse than no diagram at all.

C4 diagrams for cloud-based systems are commonly built directly from provider-specific templates. MockFlow's AWS and Azure architecture diagram generators, along with the general cloud architecture generator, give teams a fast starting point for Container-level diagrams, which pairs well with the broader guidance on what architectural diagramming actually involves and a roundup of architecture diagram tools.