Sequence diagram

A sequence diagram pins a single scenario to two axes so message order becomes unambiguous: each participant gets a vertical lifeline, and time flows strictly downward, so a message drawn lower on the page provably happens after one drawn higher — the diagram is the call order, read top to bottom.

Read the notation off the wire:

• Lifeline — a box at the top naming a participant (:ATM, bank:BankService) with a dashed vertical line dropping from it; the object exists down that whole line.
• Activation bar — a thin rectangle on a lifeline marking the span during which that object is busy executing a call (it has the stack frame).
• Synchronous call — a solid line with a filled arrowhead. The caller blocks until it returns.
• Return — a dashed line with an open arrowhead back to the caller, labelled with the value returned. Conventionally drawn only when the value matters.
• Async message — a solid line with an open (stick) arrowhead; the sender does not wait.
• Combined fragments — labelled boxes (alt for branches, loop for repetition, opt, par) that wrap a region with a guard condition in [brackets].

Worked trace: a $200 ATM withdrawal

Scenario: a customer with a $150 balance asks for $200. We trace the exact messages an LLD interview answer would draw, with concrete values, so the alt branch and the return arrows are forced to mean something. Participants: Customer (actor), :ATM, :Account, bank:BankService.

The trace makes the value-dependence explicit: because getBalance returned 150, the guard 200 > 150 selected the top arm of the alt and steps 6–7 never execute on this run. Swap the input to amount=100 and the diagram is identical except the lower arm runs instead — that is the whole point of drawing the alt rather than two separate diagrams.

Pitfalls

• Treating it as a flowchart. A sequence diagram answers "who calls whom, in what order"; it is bad at branching/looping detail. People cram nested alt/loop fragments until it is an unreadable maze — that logic belongs in an activity diagram or just pseudocode.
• Confusing the two arrowheads. A filled head is a synchronous (blocking) call; an open/stick head is asynchronous or a return. Drawing a blocking debit() with an open head silently claims fire-and-forget semantics — a real correctness lie in a payments design.
• Activation bars that don't nest. If :ATM is still active (its bar is open) it cannot have "returned" to the customer. A bar that ends before the messages it supposedly made are sent is a self-contradiction reviewers will catch.
• Forgetting the guard on an alt. An alt with two arms and no [condition] tells the reader nothing about which arm fires when. The guard is the load-bearing part.
• Modeling every method, including getters. Showing getId(), toString(), logging calls — noise that buries the one decision (the alt) that the diagram exists to communicate.
• Lifeline for a class, not an instance. The participant is an object (:Account or a:Account), not the class. Two distinct accounts in one scenario need two lifelines.

When to reach for it — and when not

UML gives you several interaction/behavior views; the skill is picking the one that makes the thing you're worried about visible.

• Choose a sequence diagram when the risk lives in ordering and collaboration: a multi-object protocol (auth handshake, two-phase commit, saga), debugging "who called the API twice", or specifying the exact call order between services. The vertical time axis is the payoff — it makes a race or an out-of-order call jump out.
• Prefer an activity diagram when the risk is the control flow within one process: heavy branching, loops, parallel forks/joins, decision logic. Sequence diagrams degrade fast under branching; activity diagrams are built for it. Cost of choosing it: you lose the explicit object-to-object call structure.
• Prefer a communication (collaboration) diagram when you care about which objects are linked more than precise timing — it shows the same messages on a graph of objects with numbered calls. Cost: message order is encoded only in the numbers, so it's much harder to eyeball a sequence; you trade temporal clarity for topology clarity.
• Prefer a state diagram when one object's behavior depends on its history/mode (a Connection that is OPEN/HALF_OPEN/CLOSED). Sequence diagrams show one path; a state machine shows all reachable transitions.

One-liner: choose a sequence diagram when the bug or design question is "in what order do these objects talk"; prefer an activity diagram when it's "what's the branching logic inside one flow", and a communication diagram when it's "which objects are even connected".

Takeaways

• Down = later. The vertical axis is a total order on messages; that ordering is the entire value proposition.
• Filled arrowhead = blocking sync call, open arrowhead = return or async — getting the head wrong misstates the contract.
• Trace a concrete run with real values: the inputs decide which alt arm fires, which is exactly what you're trying to communicate.
• One scenario per diagram. If branching dominates, you wanted an activity diagram; if topology dominates, a communication diagram.

Sources: OMG UML 2.5.1 Specification (interaction diagrams, lifelines, combined fragments and guards); Martin Fowler, UML Distilled (3rd ed., ch. on Sequence Diagrams — sync vs async messaging and when to prefer activity/communication diagrams); Grady Booch et al., The Unified Modeling Language User Guide. Re-authored and deepened for this guide: added the mechanism statement, a step-by-step $200/$150 ATM withdrawal trace, a hand-authored SVG replacing the prior unlabeled figure, a pitfalls section, and a selection/trade-offs comparison against activity, communication, and state diagrams.

When NOT to draw a sequence diagram

• Static structure questions (fields, inheritance) — use class diagrams.
• Long-running async choreography with many branches — consider activity/state or a short prose trace.

Interviewer follow-ups & drills

1. Why sequence over communication diagram? Time ordering and call stack depth are clearer for request/response.
2. Failure teaching: missing return/timeout messages hide real production hangs — always show the failure path once.
3. Drill: login with SSO — Client→App→IdP→App→Client; mark redirect vs back-channel.