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.
📍"This box is us. These are the folks and systems we talk to."
Level 2: Container Diagram
What’s inside our system?
"Container" doesn’t mean Docker here, it’s a runtime unit like:
- Web apps
- Mobile apps
- Databases
- APIs
- Background services
- Blob stores
You're breaking down the system into deployable units.
🧩 Think of it as "how we ship and run stuff."
Level 3: Component Diagram
What are the building blocks of a container?
If your Node.js app is a container, then:
- Each route handler + business logic module = component
- You show internal structure: controllers, services, utils, etc.
This is super helpful for fellow devs, especially in layered or hexagonal architectures.
🛠️ "Here's what’s inside this box, grouped by logic, not files."
Level 4: Code (Optional, Zoomed-In View)
Want to go full nerd? Here's the code-level diagram.
UML class diagrams, interfaces, functions—basically your IDE in diagram form. But this level is often skipped unless you're:
- Documenting a library
- Teaching internal architecture
- Auto-generating diagrams from code
🧬 "Here’s the guts of that service, class by class."
It’s All About Abstractions
Let’s clarify the C4 abstractions:
- Software System: The whole thing you’re building (like “LiveAPI”). Think team-level responsibility.
- Container: Something running (BE, DB, frontend app, etc).
- Component: Logical chunks inside a container (routes, services, handlers).
- Code: The actual classes, functions, modules, etc.
Common Mistakes C4 Helps Avoid
❌ Mixing abstractions (e.g., putting low-level tech in a system diagram)
❌ Unlabeled arrows (seriously, what does this line even mean?)
❌ Random colors and styles with no legend
❌ Overloaded terms like “service”, “module”, “component” without context
🛠 Tools You Can Use (But Don’t Have To)
- Structurizr DSL – Text-based C4 diagrams
- PlantUML + C4 extension
- Diagrams.net / draw.io
- Pen and paper – Seriously, it’s fine
The model is tool-agnostic on purpose.
Final Take
C4 isn’t about pretty diagrams. It’s about shared understanding.
- Junior devs get context faster.
- Seniors reason about dependencies and risks better.
- PMs and architects don’t get lost in classes and configs.
Think of it as version-controlled, zoomable documentation.
TL;DR
- C4 = 4 zoom levels of architecture (Context → Container → Component → Code)
- Keep diagrams clear, labeled, and audience-appropriate
- Great for onboarding, audits, incident reviews, threat modeling
- You don’t need fancy tools, just a consistent approach
I’ve been actively working on a super-convenient tool called LiveAPI.
LiveAPI helps you get all your backend APIs documented in a few minutes
With LiveAPI, you can quickly generate interactive API documentation that allows users to execute APIs directly from the browser.
If you’re tired of manually creating docs for your APIs, this tool might just make your life easier.
Top comments (1)
been nice seeing stuff that actually makes system docs less painful, honestly - you ever feel like half the diagrams out there are just for show instead of actually being helpful?