Skip to content

System Architecture (C4 / arc42)

How services compose, where boundaries fall, what depends on what. Drawn at the level of detail the brief needs — and no more. The map a new dev reads in their first week and a Tech Lead points at in every Epic kickoff.

Owners: Tech Lead Phase it lives in: What We Build (Volume III) The corpus principle this enacts: Resolution, not maximum.

Where it lives in the chain

How to do this

The C4 model gives four levels, used at different times:

  1. Context — the system as a black box, with its users and external dependencies. One diagram for the product. Updated rarely.
  2. Containers — services, databases, queues, frontends. One diagram per product. Updated when services are added or removed.
  3. Components — inside one container. One diagram per service. Updated when a service is significantly refactored.
  4. Code — class-level. Almost never drawn manually. Generated if needed.

The discipline: draw the level the audience needs. A new dev needs Context and Containers. An Epic kickoff for a single service needs Components. Code-level diagrams are usually wasted effort.

What good practice looks like

The Context and Container diagrams live in the repo, as Mermaid or PlantUML, not as Confluence screenshots. They are updated by PR when the system changes — same review discipline as code. A diagram that doesn't match the running system is worse than no diagram, because it lies to readers who trust it.

The diagrams omit detail to be readable. A Container diagram with 40 boxes is unreadable; if there are 40 services, the diagram needs grouping (by domain, by team, by lifecycle). The chain's discipline is the same as for documents: enough to read, not enough to ship.

arc42 is an alternative framing — same idea, twelve sections instead of four levels. Use whichever fits the team's writing culture. Both are better than no map.

200apps · How We Work · NWIRE