Beyond the four static C4 levels, what do C4's supplementary dynamic and deployment diagrams add, and what question does each answer that a container diagram cannot?

## Why supplementary views exist The four core C4 levels (Context, Container, Component, Code) are all **static structure**. Two important classes of question fall outside them: 1. **"In what order does anything happen?"** — A container diagram showing `Web → API → DB` and `API → Broker` does not tell you whether the broker publish happens before or after the DB write, whether the caller waits, what happens if step 3 times out, or how many round trips a single user action costs. 2. **"Where does this run, and how many of them are there?"** — A container diagram shows one logical `Orders API`; production may run 12 instances across 3 availability zones behind a load balancer, plus a separate single-instance staging deployment. ## Dynamic diagram - **What it is:** a collaboration-style view over elements that already exist in the model (containers or components), where interactions are **numbered** to convey order (`1`, `2`, `2.1`, `3`), or drawn as a sequence diagram with lifelines. - **Scope discipline:** one diagram = one scenario, named in the title ("Dynamic view — Customer places an order"). Two or three well-chosen scenarios (the money path, the auth path, the worst failure path) beat exhaustive coverage. - **What it exposes:** synchronous call chains and their compounded latency/failure probability; excessive round trips; hidden fan-out; ordering assumptions between a database write and an event publish (the dual-write problem); compensation steps in a saga; retry and timeout placement. - **Relation to UML:** conceptually a UML communication or sequence diagram; C4 simply says to reuse elements from the model rather than inventing new boxes. - **Automation:** distributed tracing tools can emit real sequence views; use those as evidence of the *actual* flow and keep the hand-drawn one for the *intended* flow. ## Deployment diagram - **Elements:** **deployment nodes**, which nest arbitrarily (`AWS eu-west-1` → `AZ-a` → `EKS cluster` → `pod` → `JVM`), each optionally with an **instance count** and environment-specific properties; **container instances** placed inside those nodes; and **infrastructure nodes** (load balancers, DNS, firewalls, CDNs) that are not containers of your system but matter to the topology. - **One per environment:** the production topology and the developer-laptop topology are different diagrams over the *same* logical model — which is precisely the payoff of a model-based tool. - **What it answers:** redundancy and failure domains (is anything a single instance?), co-location (do two containers share a host and therefore a failure mode?), network hops and trust boundaries (essential to threat modelling — every path crossing a boundary needs authn/authz/encryption), data residency, and cost/scaling shape. - **Drift risk:** highest of all views in cloud environments. Keep it at the level of *stable topology* (tiers, zones, node types) rather than instance IDs, or generate it from infrastructure-as-code. ## System Landscape diagram Above level 1: all the software systems in a department or enterprise and the people who use them, without opening any of them. Useful for portfolio conversations, ownership mapping, and finding duplication; useless for engineering detail. ## Putting it together — a practical set For a typical service-based product, a sufficient maintained set is: one Context, one Container, component views only for the one or two genuinely complex containers, one production Deployment view, and two or three Dynamic views for the critical scenarios. Everything else is generated on demand or drawn on a whiteboard and thrown away. ## Pitfalls - **Turning the dynamic view into a spec.** It is an illustration of a scenario, not an exhaustive behavioural contract; sequence diagrams with 40 messages usually indicate a design problem rather than a documentation problem. - **Inventing new elements** on a dynamic or deployment view that do not exist in the static model — that is exactly the inconsistency the model is meant to prevent. - **A single deployment diagram claiming to cover all environments**, which ends up true of none. - **Omitting multiplicity**, which hides whether anything is actually redundant.