Interaction Modelling
Showing the ordered exchange of messages between participants over time, to reason about protocols, failure points and latency.
Structural diagrams show what exists. Interaction diagrams show what happens, and there are questions only they can answer.
Where they earn their cost:
Distributed protocols — a saga, a two-phase interaction, an authentication flow, a payment authorisation. The ordering is the design, and prose describing it is reliably ambiguous.
Failure analysis. Marking what happens if each step fails, and what state the system is left in, turns a diagram into a design review. This is the highest-value use and the one usually skipped.
Latency reasoning. Sequential calls are additive; the diagram makes visible which could be parallelised and where the round trips accumulate.
Explaining an incident. A timeline of what actually happened, drawn as a sequence, communicates more in one image than pages of narrative.
The discipline that keeps them useful: one scenario per diagram — the happy path in one, each significant failure in another. A diagram with a dozen conditional branches is unreadable, and the branches are precisely what deserve separate treatment.
And draw them for the interactions that are hard, not for every endpoint. A sequence diagram of a simple CRUD call is documentation nobody needed.