Sequence Diagrams
Ordered message exchange, and walking the failure of each arrow.
5 to work through
-
intermediate
A checkout sequence diagram has six participants and every arrow is a plain synchronous call with no timeout written on it. In production the fourth participant starts answering in 9 seconds instead of 200 ms and never returns an error. What happens second by second, what stops it, and what should the diagram have carried?
3 min answer -
intermediate
A logistics platform's engineers cannot explain what happens when a delivery is attempted and fails. What communication artefact would help most?
2 min answer -
intermediate
A multi-step order flow with compensations is described in prose and nobody agrees on the behaviour. What does a sequence diagram add, and what must it show?
2 min answer -
intermediate
Two engineers disagree about what happens when a customer cancels an order, and both have been on the team for years. Rather than settle it in the meeting, what do you do, and what will you probably find?
2 min answer -
intermediate
What can a sequence diagram show that a component diagram cannot, and what is the rule for drawing one worth having?
2 min answer
2 terms in this topic
Interaction Modelling
Showing the ordered exchange of messages between participants over time, to reason about protocols, failure points and latency.
practiceSequence Diagrams
Showing the order of interactions over time — the only common diagram that makes latency, ordering and failure behaviour visible.
Neighbouring topics
Architecture Communication
General material on communicating architecture.
Architecture Diagrams
Choosing an audience and refusing to mix levels of abstraction.
C4 Model
Context, container, component and code as four separate diagrams.
Context Diagrams
The system as one box, with its users and external systems.
Data-Flow Diagrams
Following the data across trust boundaries rather than the calls.
Deployment Diagrams
What runs where, in which zone, behind which boundary.
Communicating Threat Models
Making risk legible to people who will fund or accept it.
Writing Decision Records
Context, alternatives and consequences, written once and never edited.
Technical Proposals
A written argument circulated before the decision feels made.
Architecture Reviews
Reviewing early enough to influence rather than to veto.
Presenting to Executives
Decision first, cost, risk, and what happens if we do nothing.
Presenting to Engineers
Mechanism, alternatives rejected, and what you are unsure about.
Explaining Trade-offs
Naming what was given up, and the condition that would change it.
Handling Disagreement
Arguing from consequences, and escalating in the room.
Negotiation
Trading on interests rather than positions, with priced options.
Documentation Practice
Keeping documents close to the code and honest about staleness.
Presentation Skills
Structure, pacing and the slide that carries the decision.
Written Communication
Writing that survives being read without you in the room.
Facilitation
Running a design session that reaches a decision.