Overview Introduction
Welcome to Module 3, where we take the first meaningful zoom into the technical heart of your software system with Level 2: Container Diagrams.
Having established the high-level boundaries and purpose in the System Context Diagram (Level 1), we now shift focus to answer the next natural set of questions that every technical stakeholder asks:
- What are the major building blocks that actually run and deliver this system?
- How are those blocks deployed, scaled, and communicated?
- Which technologies and architectural styles have been chosen — and why?
The Container Diagram is the bridge between the big-picture business view and the detailed implementation. It reveals your software system as a collection of separately runnable or deployable units — the high-level technical components that make the system work in the real world.
What Exactly Is a “Container” in the C4 Model?
Important clarification right up front:
In the C4 Model, a Container is not the same as a Docker container (although a Docker container can be one way to deploy a C4 container).
A C4 Container is defined as:
A separately runnable / deployable unit of software that executes code or hosts data.
Examples include:
- Web applications (e.g., a Spring Boot backend, a React single-page app)
- Mobile apps (iOS/Android native or cross-platform)
- API gateways / reverse proxies
- Databases (relational like PostgreSQL, NoSQL like MongoDB, caches like Redis)
- Message brokers / queues (RabbitMQ, Kafka, AWS SQS)
- Serverless functions (AWS Lambda, Azure Functions)
- Batch jobs / scheduled workers
- File storage / blob stores
- Third-party SaaS services treated as black boxes (if they form a distinct deployable boundary)
Each container is a cohesive unit that can be developed, deployed, scaled, secured, and monitored somewhat independently — even if they ultimately run on the same infrastructure.
Why the Container Diagram Matters
This level is where architecture starts to become actionable for developers, architects, DevOps, and operations teams:
- It shows the major technology choices and communication patterns (HTTP/REST, gRPC, messaging, JDBC, file-based, etc.).
- It exposes integration points, potential bottlenecks, single points of failure, and security boundaries.
- It clarifies deployment boundaries — which parts can be independently released, scaled, or replaced?
- It serves as the blueprint for infrastructure (cloud resources, Kubernetes namespaces, load balancers, networks).
- It is the ideal level for most architecture discussions, threat modeling, capacity planning, and onboarding new team members to the technical structure.
Unlike the System Context (purely business-oriented), the Container Diagram introduces just enough technical detail to be useful without overwhelming anyone with code-level complexity.
What You’ll Learn and Build in This Module
In Module 3, we will cover:
- Precisely defining what qualifies as a container (and what doesn’t).
- Distinguishing containers from components (Level 3) and from infrastructure/deployment concerns.
- Identifying and naming containers using clear, meaningful labels.
- Mapping responsibilities, technologies, and protocols to each container.
- Drawing clean, directional relationships that show how containers interact.
- Avoiding common anti-patterns (monolithic “everything” containers, technology leakage, unclear boundaries).
- Hands-on creation using C4-PlantUML Studio (or similar tools) to turn your System Context into a fully fleshed-out Container Diagram — with live previews, iterative refinement, and exportable visuals.
By the end of this module, you will be comfortable producing professional Container Diagrams that clearly communicate the high-level technical architecture of any system — setting the perfect stage for zooming even further into Components in Module 4.
This is where the C4 Model transitions from “what the system does” to “how it’s technically built and runs” — and it’s one of the most frequently used levels in real-world teams.
Let’s open the hood, identify the major moving parts, and start mapping the technical landscape — container by container! 🚀