C4 Model Architecture Diagrams Explained (with AI Examples, 2026)

The C4 model is a hierarchical approach to documenting software architecture using four levels of detail: System Context, Container, Component, and Code. Created by Simon Brown, the C4 model is intentionally simple - it borrows from how Google Maps lets you zoom from a country down to a street. Engineering teams use C4 because it produces consistent, scoped diagrams that match how humans naturally explore an unfamiliar system: from the outside in, one zoom level at a time.

The C4 model has become one of the most widely adopted approaches to software architecture documentation in the last decade. It is used at organisations like Capital One, the UK Government Digital Service, and many engineering teams that need a lightweight alternative to UML or ArchiMate. This guide explains each level, when to use it, and how to generate C4 diagrams with AI in seconds.

What problem does C4 solve?

Most architecture diagrams fail in one of two ways: they show too much (every microservice on a single canvas, with arrows everywhere) or too little (a box labelled "Backend" with no detail). C4 solves this by forcing the diagram author to choose a zoom level. Each level has a clear scope, audience, and shape vocabulary.

The four C4 levels

Level 1: System Context

The System Context diagram shows your software system as a single box, plus the people and external systems it interacts with. It answers the question: "What does this system do, and who and what does it talk to?" This is the diagram you put at the top of any architecture document.

Level 2: Container

The Container diagram zooms into the system box from level 1 and shows the deployable units inside - typically the web app, API, database, background workers, and any queues. "Container" here means a deployable thing (a Docker container, a serverless function, a database), not specifically a Linux container.

Level 3: Component

The Component diagram zooms into one container and shows the major modules or components inside it - typically organised by responsibility (authentication, billing, reporting, etc.). At this level, the audience is engineers working on the codebase.

Level 4: Code

The Code diagram is essentially a UML class diagram for one component. Most teams skip this level entirely - modern IDEs auto-generate class diagrams from source - but it can be useful for teaching or for highly complex components.

Supporting C4 diagrams

Beyond the four core levels, the C4 model includes supplementary diagrams:

• System Landscape - one level above the System Context, showing multiple systems in an organisation and how they relate
• Dynamic diagrams - show how containers or components collaborate to handle a specific use case (similar to a sequence diagram but using C4 shapes)
• Deployment diagrams - map the containers from level 2 to physical or cloud infrastructure

Common mistakes when adopting C4

Mixing levels

The most common mistake is putting components on a System Context diagram or showing classes on a Container diagram. The whole value of C4 is consistent zoom level. If a shape doesn't belong at the current level, it goes on a different diagram.

Trying to draw every component

You don't need a Component diagram for every container. Most teams only draw Component diagrams for containers that need explanation - complex services, security-sensitive paths, or areas with high churn.

Forgetting to label arrows

Every relationship in a C4 diagram should be labelled with what passes across it ("reads users via JSON/HTTPS", "publishes events via AMQP"). Unlabeled arrows force readers to guess.

Generating C4 diagrams with AI

AI-powered diagram tools work well for C4 because the four levels map cleanly to four distinct prompts. The trick is to keep each prompt scoped to a single level - mixing levels in a prompt produces messy output.

A practical workflow:

1. Write the System Context prompt and generate diagram 1.
2. Write the Container prompt by "zooming into" the system box, and generate diagram 2.
3. For each container that warrants more detail, write a Component prompt and generate diagram 3.
4. Save the prompts alongside the source code so teammates can regenerate diagrams when the system changes.

Frequently asked questions

Is C4 a replacement for UML?

For day-to-day architecture documentation, yes. UML covers far more diagram types than most teams need; C4 covers the 80% case (systems, containers, components) with a much smaller learning curve. UML class diagrams are still useful at the Code level if you need them.

Do I need to draw all four levels?

No. Most teams draw levels 1 and 2 and only draw level 3 selectively. Level 4 is optional and rarely produced manually - IDEs generate it automatically when needed.

Where do cloud architecture diagrams fit in?

Cloud architecture diagrams (e.g., AWS or Azure stack diagrams) map to the C4 Deployment diagram. They show how your containers run on physical or cloud infrastructure - load balancers, VMs, managed services - and complement, rather than replace, the Container diagram.

Try it

Read the software architecture documentation guide for how C4 fits into a broader documentation strategy, see microservice architecture patterns for examples at the Container level, or generate a C4 diagram now at ArchitectureDiagram.ai.