Supporting Diagrams
The four core C4 diagrams — Context, Container, Component, and Code — are powerful, but they all share one characteristic: they describe the static structure of a system. They show what the pieces are and how they're wired together, frozen in place. They deliberately say nothing about two other questions that teams inevitably ask:
- How do these pieces behave together at runtime, step by step?
- Where does all of this actually run?
To answer those, the C4 model offers three supporting diagrams. They're optional, you reach for them only when the static views leave a gap, and each layers a new dimension on top of the abstractions you already understand. Think of them less as new zoom levels and more as different lenses on the same system.
System Landscape diagram — the enterprise big picture
The System Context diagram deliberately keeps one system in the spotlight. But real organizations run dozens or hundreds of systems, and sometimes you need to step back even further than a single Context diagram allows — to see the whole forest, not just one tree.
The System Landscape diagram does exactly that. It shows the "big picture" of the entire IT estate: all the software systems across an enterprise (or a business unit), the people who use them, and how those systems relate to one another — regardless of which team owns what. If a System Context diagram is your country, the System Landscape is the whole world map of your organization's software.
It's especially useful for enterprise architects, for planning, and for onboarding people who need to understand how many moving systems exist before diving into any one of them. The trade-off is that it stays at a very high level of abstraction — it names systems, not their internals — precisely so it doesn't collapse under its own complexity.
Dynamic diagram — behavior at runtime
Static diagrams show that the Order Controller can talk to the Payment Service. They don't show the order of events when a specific thing happens. But often the most important question is behavioral: "walk me through exactly what happens, step by step, when a customer places an order."
The Dynamic diagram answers that. It's similar in spirit to a UML sequence or collaboration diagram, but it reuses the C4 elements you already know — people, systems, containers, or components — and adds numbered steps to show the flow of interactions for one specific use case or user story.
For example, a Dynamic diagram of "customer checks out" might read:
- Customer submits the order via the Web Application.
- Web Application calls the Backend API's Order Controller.
- Order Controller asks the Security Component to validate the session.
- Order Controller calls the Payment Service.
- Payment Service calls the external Payment Gateway.
- On success, the API writes the order to the Database and triggers a confirmation email.
The key thing that makes it a C4 Dynamic diagram rather than a generic sequence diagram is that the boxes are the same abstractions from your other diagrams — so the reader is never learning a new vocabulary. You can draw a Dynamic diagram at any level (between systems, between containers, or between components), depending on how much detail the use case demands.
Deployment diagram — where it actually runs
Every diagram so far has answered "what is the software made of?" The Deployment diagram answers a completely different question: "where does the software physically run?"
It maps the containers from your Container diagram onto the actual infrastructure they're deployed to — physical servers, virtual machines, cloud services, Docker containers, Kubernetes pods, data centers, regions. One logical container from the static model might map to many running instances across several servers; the Deployment diagram is where that reality becomes visible.
This is the natural home for the operational and infrastructure conversation. It's the diagram the ops team, SREs, and anyone doing a security or resilience review will care about most — because it shows load balancers, redundancy, environments (dev/staging/production), and cloud topology. It's also, notably, the diagram where a Docker container legitimately shows up as infrastructure — a nice bookend to the "a C4 container isn't a Docker container" caution from Level 2. Here, the two ideas finally meet: your logical containers get deployed onto infrastructure that may well include Docker.
When to reach for each
You won't draw all of these for every project, and that's the point. A quick guide:
| If you need to show… | Reach for… |
|---|---|
| How many systems exist across the whole organization | System Landscape |
| The step-by-step flow of a specific use case at runtime | Dynamic |
| Where the software is deployed and on what infrastructure | Deployment |
Most teams start with just Context and Container diagrams, add a Component diagram for their trickiest containers, and pull in a supporting diagram only when a real question demands it — a stakeholder asking "how does checkout actually work?" (Dynamic) or an ops review asking "what runs where?" (Deployment). Draw them on demand, in response to a genuine need, and they stay valuable instead of becoming maintenance debt.
Where we're headed
We've now covered every diagram the C4 model offers — the four core levels plus these three supporting lenses. But a nagging problem has followed us the whole way: all of these diagrams go stale the moment the system changes. That single problem is why the tooling you choose matters enormously — and why the future of C4 is "Architecture as Code." That's the subject of the next section.
Previous: ← Level 4: Code · Next: Tooling →