Making Sense of Software Architecture with the C4 Model
Ever tried explaining your system architecture and ended up drawing a bunch of rectangles that confused everyone, including you? Yeah, same. That’s where the C4 model comes in, it’s like Google Maps for your codebase. Zoom in, zoom out, show only what matters, and skip the fluff. Let’s break it down, dev-to-dev. Why Should You Care? Because "drawing boxes and lines" isn't enough. Diagrams should communicate, not decorate. Whether it’s onboarding a new hire, defending your architecture in a review, or just making sense of a spaghetti monolith, you need clarity. C4 is: Notation-agnostic (use boxes, colors, ASCII art—your call) Tooling-independent (draw on paper, use diagrams.net, Structurizr, etc.) Easy to learn (no need to memorize UML specs) Focused on abstractions and levels of detail Level 1: A system context diagram provides a starting point, showing how the software system in scope fits into the world around it. Level 2: A container diagram zooms into the software system in scope, showing the applications and data stores inside it. Level 3: A component diagram zooms into an individual container, showing the components inside it. Level 4: A code diagram (e.g. UML class) can be used to zoom into an individual component, showing how that component is implemented at the code level. The 4 Levels in C4 (Context, Containers, Components, Code) Think zoom levels. Each level answers a different question. Level 1: System Context Diagram What are we building and who/what interacts with it? Show your system as a box. Surround it with people, APIs, 3rd-party services, etc. Useful for: stakeholders, managers, onboarding slides.

Ever tried explaining your system architecture and ended up drawing a bunch of rectangles that confused everyone, including you? Yeah, same.
That’s where the C4 model comes in, it’s like Google Maps for your codebase.
Zoom in, zoom out, show only what matters, and skip the fluff.
Let’s break it down, dev-to-dev.
Why Should You Care?
Because "drawing boxes and lines" isn't enough.
Diagrams should communicate, not decorate.
Whether it’s onboarding a new hire, defending your architecture in a review, or just making sense of a spaghetti monolith, you need clarity.
C4 is:
- Notation-agnostic (use boxes, colors, ASCII art—your call)
- Tooling-independent (draw on paper, use diagrams.net, Structurizr, etc.)
- Easy to learn (no need to memorize UML specs)
- Focused on abstractions and levels of detail
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Level 1: A system context diagram provides a starting point, showing how the software system in scope fits into the world around it. |
Level 2: A container diagram zooms into the software system in scope, showing the applications and data stores inside it. |
Level 3: A component diagram zooms into an individual container, showing the components inside it. |
Level 4: A code diagram (e.g. UML class) can be used to zoom into an individual component, showing how that component is implemented at the code level. |
The 4 Levels in C4 (Context, Containers, Components, Code)
Think zoom levels. Each level answers a different question.
Level 1: System Context Diagram
What are we building and who/what interacts with it?
- Show your system as a box.
- Surround it with people, APIs, 3rd-party services, etc.
- Useful for: stakeholders, managers, onboarding slides.