C4 model in a systems analyst interview
Contents:
Why interviewers ask about C4
C4 is the lightweight architecture notation that quietly replaced heavyweight UML in most modern engineering orgs. When a hiring manager at Stripe, Notion, or Airbnb asks a systems analyst candidate to "sketch the architecture of a service you've worked on", they are almost always looking for a C4-shaped answer: context, then container, stop before you bore them. Knowing the four levels and when to skip three of them is the difference between sounding like a senior analyst and sounding like someone who memorized a textbook.
The model was created by Simon Brown around 2018 and is now the default whiteboard format at companies that care about diagrams aging well. Most interviewers will not ask "what is C4" by name — they will ask you to draw a system, and you are graded on whether your picture is legible to a new joiner six months later. C4 gives you a recipe for that.
In practice the SA interview pattern is one of three: explain a diagram you brought, redraw a system you worked on, or design a new system live. In all three, C4 is the structure that lets you zoom in and out without spaghetti boxes.
The four levels at a glance
C4 stacks four levels of abstraction. Each level answers a different question and serves a different audience.
| Level | Name | Answers | Audience |
|---|---|---|---|
| C1 | System Context | Where does the system sit in the world? | Execs, business stakeholders, new hires |
| C2 | Container | What runtime pieces make up the system? | Engineers, architects, DevOps |
| C3 | Component | What modules live inside one container? | Engineers of that container |
| C4 | Code | What classes / data structures live inside one component? | Same engineers, rarely drawn by hand |
Load-bearing rule: in a 45-minute interview you will almost always stop at C2. C3 is selective. C4 is for legacy UML enthusiasts and code generators.
Level 1: System Context
The System Context diagram answers "what does this system do in the wider universe". One box for your system, surrounding boxes for the people (users, admins, ops) and external systems (payment gateways, identity providers, email vendors) that interact with it.
[Customer] [Support agent]
| |
v v
+----> [Checkout Service] <+
|
| uses
v
[Stripe + SendGrid]What the interviewer is checking: do you mention actors as people, not roles in your code, do you draw only the boxes that matter for the conversation, and do you label the arrows with the intent rather than the protocol? At this level REST / gRPC / Kafka are noise — save them for C2.
A clean Level 1 has no more than one focal system and 5-8 external boxes. If your picture has 14 external systems you have either picked the wrong scope or you are showing landscape, not context.
Most candidates skip this level and dive straight into containers — that is the single fastest way to lose a senior interviewer.
Level 2: Container
A container in C4 is not a Docker container. It is anything separately runnable or deployable: a single-page app, a backend service, a database, a message broker, a worker, a scheduled job. The naming clash is unfortunate and you should call it out in the interview before the interviewer does — that earns half a point.
[Customer]
| HTTPS
v
[Web SPA: React] -- REST/JSON --> [API: Go service] -- SQL --> [Postgres]
|
+--> [Redis cache]
+--> [Kafka: order.events]The Container diagram is the workhorse of any SA interview. It is the level where you specify technology, protocol, and direction of every arrow. "Web App" is not enough — write "Web App (React 19, hosted on Vercel)". Generic boxes get a polite nod; specific boxes get follow-up questions, and follow-up questions are good.
A useful sanity check: every arrow should answer three questions — who initiates the call, what protocol, what payload shape. If your arrow says only "talks to", you are skipping the part interviewers grade on.
Level 3: Component
Inside one container you have components — logical modules grouped by responsibility. Controllers, services, repositories, adapters.
[API: Go service]
|-- [AuthHandler]
|-- [OrderHandler]
|-- [PaymentService] -- HTTPS --> [Stripe API]
|-- [OrderRepository] -- SQL --> [Postgres]
+-- [EmailNotifier] -- SMTP --> [SendGrid]In real engineering teams Level 3 diagrams age fastest — they go stale within two sprints because component boundaries inside a service shift constantly. Brown himself recommends generating them from code when possible (with tools like structurizr or arc42 extensions) and treating them as disposable.
In an interview, draw C3 only if asked or only if your story specifically hinges on a single container being too complex for one box. Otherwise stay at C2 and answer the follow-ups.
Level 4: Code
C4 at Level 4 is UML class diagrams inside a single component. In practice almost nobody draws this manually — modern IDEs and tools like PlantUML or Mermaid generate it from source. You are not expected to draw it in an interview. If an interviewer asks, the right answer is "I would generate it from code rather than hand-draw, because at this level the diagram drifts from reality within a week."
Supplementary diagrams
Beyond the four levels, C4 defines three supplementary diagrams that show up in interviews more often than people expect.
Deployment diagram. Where the containers actually run — cloud regions, Kubernetes nodes, autoscaling groups, edge functions. This is increasingly the diagram interviewers care about because every modern system is multi-region.
[AWS eu-west-1]
|-- [ECS Fargate]
| +-- [API container x6]
|-- [RDS Postgres: 1 primary + 2 replicas]
+-- [ElastiCache Redis]Dynamic diagram. A sequence-style view showing the flow between containers or components for one concrete scenario — "a customer places an order during a flash sale". This is the format senior interviewers love because it forces you to think about ordering, failure modes, and retries.
System Landscape diagram. Multiple systems and their shared dependencies — useful at platform companies like Databricks or Snowflake where one team owns a service that ten others consume. Rare for junior SA roles, common at the staff level.
Common pitfalls
The most common pitfall is packing too many containers onto one diagram. Past roughly twelve containers the picture stops being readable and starts being decoration. The fix is to introduce a System Landscape at one level above and a Container diagram per logical system at C2 — interviewers reward decomposition, not density.
A second trap is confusing containers with components. A container is independently deployable and has its own process or runtime; a component is a module inside that process. Candidates who say "the OrderService is a container" when they mean a Go struct lose credibility instantly. The simple test: if you can deploy it without deploying the rest, it is a container; if you cannot, it is a component.
Third pitfall: drawing all four levels for every system. Most production architectures only need C1 and C2. Level 3 is selective, level 4 is almost never drawn by humans. Candidates who insist on showing four diagrams during a one-hour interview tell the interviewer they have not internalized the model — they have memorized the rules without understanding the tradeoffs.
Fourth: ignoring deployment. Saying "we run on AWS" is not enough. Multi-region, autoscaling, failover, blast radius — these are the questions a senior SA gets asked, and the deployment diagram is where you answer them. If your story has a Postgres instance with no replica, expect a follow-up about what happens at 3 AM when the primary dies.
Fifth, and the most subtle: unlabeled or weakly labeled arrows. "Talks to" is not a label. "Publishes order.created events via Kafka topic, partitioned by customer_id, with at-least-once delivery" — that is a label. Strong arrows are what separate a passable diagram from one that triggers nodding from the interviewer.
Sixth: using full UML notation inside C4. The whole point of C4 is to be simpler than UML. Mixing aggregations, multiplicities, and stereotypes confuses the picture. Stay with boxes, lines, and short text labels.
Related reading
- Acceptance criteria with Given-When-Then for systems analysts
- Cache strategies in a systems analyst interview
- Kafka in a systems analyst interview
- SQL injection and XSS for systems analysts
- Case interview for systems analysts
If you want to drill SA interview questions like this every day, naildd ships with 1,500+ problems across exactly this pattern.
FAQ
Where should I actually draw C4 diagrams?
The native tool is Structurizr (built by Simon Brown himself), which renders all four levels from a DSL. Mermaid added native C4 support around 2022 and is the easiest option if you live in Markdown — it embeds directly in GitHub, Notion, and most docs sites. draw.io / diagrams.net is the whiteboard-style alternative, and PlantUML with the C4 extension works for teams that already use it. For a live interview, plain text boxes with arrows are fine — interviewers care about the structure, not the rendering.
Can I use C4 in a strict enterprise setting that still mandates UML?
Yes, but rarely as the only documentation. Banks, healthcare systems, and regulated industries usually keep some formal UML for compliance reasons and use C4 in parallel for engineering communication and onboarding. The trick in those orgs is to keep the two artifacts separate: C4 for talking to humans, UML for talking to auditors. Mixing them in one diagram is the worst of both worlds.
Is C4 official or standardized?
C4 is not an ISO standard and is not owned by the OMG (the body behind UML). It is a published method from Simon Brown documented at c4model.com, and the community has converged on it because it is useful, not because it is mandated. In an interview, if asked, say exactly that — interviewers respect candidates who know what is standardized and what is convention.
How is C4 different from arc42 or the 4+1 view model?
arc42 is a template for the entire architecture document — quality attributes, decisions, risks, deployment — and often uses C4 diagrams inside it. 4+1 (Kruchten, 1995) is older and splits views into logical, process, physical, development, plus scenarios; it predates the container-everything era and is heavier. C4 is a notation; arc42 is a document structure; 4+1 is a taxonomy. They are not competitors and many teams use C4 inside arc42.
Do I need to memorize the C4 notation rules?
No. The notation is intentionally loose — boxes, lines, text labels, optional colors. The mistake to avoid is drawing UML notation by reflex (open arrowheads for inheritance, diamonds for aggregation) when you are supposed to be drawing C4. Keep it boxes-and-arrows, label everything, and you are following the spec.
What questions do senior SA interviewers ask after the C4 diagram?
The standard follow-ups: what happens if container X dies, how do you handle schema migrations on the database, what is the blast radius of a deployment, how do you observe the system, what is the SLO and how do you measure it. The diagram is the setup; the value is in answering these crisply. Practicing the diagram without the follow-ups gets you to mid-level. Practicing both gets you to senior.