Low Level Design Foundations

Sequence Diagrams

Lifelines, messages, activations. The narration the interviewer is reading along with as you talk through a flow.

Concept Foundational
10 min read
uml sequence-diagram lifeline message lld

Summary#

A sequence diagram is the flow picture: for a single use case, what message goes from which object to which other object, in what order. The class diagram says what exists; the sequence diagram says what happens. The interviewer reads it as a score that runs alongside your verbal narration of the flow — if your narration and the diagram diverge, the diagram wins.

The notation reduces to a handful of primitives:

  • Lifeline — a labelled box at the top representing an object or actor, with a dashed vertical line dropping down beneath it. Time flows top-to-bottom. One lifeline per participant in the flow.
  • Message — a horizontal arrow from one lifeline to another, labelled with the method name or message verb. Solid line with a filled arrowhead for synchronous calls; dashed line with an open arrowhead for return values; solid line with an open arrowhead for asynchronous or one-way messages.
  • Activation bar — a thin vertical rectangle on a lifeline showing when that object is executing in response to a message. Activations stack when one method calls another on the same object.
  • Self-call — an arrow that loops back to the same lifeline, used when an object calls one of its own methods inside the current activation.
  • Fragments — labelled boxes around a group of messages: `alt` (alternative branches), `opt` (optional), `loop` (repeated), `par` (parallel), `ref` (reference to another diagram).

That is enough to draw any sequence diagram an LLD interview will demand.

Why it matters#

The sequence diagram is where the interviewer catches missing responsibilities. The way they catch them is brutally simple: you describe a flow verbally, you try to draw it, and you reach an arrow that has nowhere to land. The lifeline you need does not exist on your class diagram, or the object you tried to message does not have the method the arrow is labelled with. The diagram has surfaced a hole the prose hid.

Three specific things the sequence diagram tests:

Object boundaries. A class diagram can look respectable while still letting one object do too much. The sequence diagram makes it visible: if every arrow lands on the same lifeline, you have a god object, even if the class diagram disguised it. Healthy sequence diagrams have arrows fanning across three to six lifelines for a meaningful flow.

Direction of dependency. Each arrow is a coupling claim. Does Order call Payment, or Payment call Order? The diagram forces you to pick, and the choice has consequences for the class diagram: an arrow from A to B implies A holds a reference to B. If your arrows contradict the references shown in the class diagram, one of the two is wrong.

Synchronous versus asynchronous. When the candidate says “the payment gateway processes the charge,” the unspoken question is whether the call blocks. A filled arrowhead says yes (and your code waits, with whatever timeout consequences that implies). An open arrowhead says no (and your code needs a separate path to receive the result). Drawing the wrong arrow tip is a common error and one the interviewer notices.

The diagram is also the most powerful artefact for follow-up questions. “What happens if the payment gateway is slow?” becomes a concrete edit to the diagram — add a timeout, add a retry, draw the resulting alternative branch. Verbally, those changes are vague; on the diagram, they are precise.

How it works#

A canonical mini sequence diagram for the parking lot’s entry flow:

   Driver        EntryGate     ParkingLot     Floor       ParkingSpot     Ticket
     |               |              |            |              |              |
     | park(v)       |              |            |              |              |
     |-------------->|              |            |              |              |
     |               | parkVehicle(v)            |              |              |
     |               |------------->|            |              |              |
     |               |              | findFreeSpot(v)           |              |
     |               |              |----------->|              |              |
     |               |              |            | fits(v)?     |              |
     |               |              |            |------------->|              |
     |               |              |            |        true  |              |
     |               |              |            |<-------------|              |
     |               |              |     spot   |              |              |
     |               |              |<-----------|              |              |
     |               |              |--- new Ticket(v, spot) -------------->   |
     |               |              |                                           |
     |               |              | assign(t)                 |              |
     |               |              |-------------------------->|              |
     |               |     ticket   |                                          |
     |               |<-------------|                                          |
     | ticket        |              |                                          |
     |<--------------|              |                                          |

Reading this:

  • Six lifelines, two of which are actors (Driver) or boundary objects (EntryGate) and four of which are domain objects.
  • Time flows downward; the first message is at the top.
  • Synchronous calls (solid arrow with filled head) go right; return values (dashed arrow with open head) go left.
  • The new Ticket(...) arrow ends at the Ticket lifeline — a creation message, sometimes drawn ending at the lifeline’s box rather than below it.
  • The Driver waits on the EntryGate, which waits on the ParkingLot — the activations would stack on each lifeline if we drew them explicitly.

Activations#

The vertical bar on a lifeline shows that the object is executing. Activations matter for two reasons: they make nested calls visible, and they make the call/return pairing unambiguous.

   Caller            Callee
     |                  |
     |   doWork()       |
     |----------------->|XX|       <- activation starts when callee receives
     |                  |XX|       <- the call; ends when callee returns.
     |                  |XX|
     |        result    |XX|
     |<-----------------|XX|       <- dashed return arrow
     |                  |

In hand-drawn ASCII, the activation bar is often elided — the call/return pair is enough. In tools like PlantUML, the bar is drawn explicitly. Either is fine in an interview; what matters is that every synchronous call has a return.

Self-calls and nested calls#

A self-call is an arrow from a lifeline back to itself:

   ParkingLot
     |
     |  parkVehicle(v)
     |--->|
     |    | validate(v)        <- self-call
     |    |---->|
     |    |     |
     |    |<----|
     |    |
     |    | findFloor(v)       <- self-call
     |    |---->|
     |    |<----|
     |<---|

Self-calls are useful but easily overused. If a lifeline has four nested self-calls, the diagram is showing pseudocode rather than object collaboration. Push the internal steps into the verbal narration and let the diagram show only the messages that cross object boundaries.

Fragments: alt, opt, loop#

When the flow has branches or repetition, the alt, opt, and loop fragments wrap the relevant messages.

`alt` for two-way alternatives:

   ParkingLot      Floor
     |               |
     +---------------+----- alt [free spot found]
     |               |
     |  findFreeSpot |
     |-------------->|
     |     spot      |
     |<--------------|
     |               |
     +---- else -----+
     |               |
     |  throw NoSpotAvailable
     |               |
     +---------------+

`opt` for “happens only if condition holds.” `loop` wraps messages that repeat until a guard fails. The fragment label sits in the top-left corner; the guard `[condition]` in brackets next to it.

Use sparingly. A sequence diagram with three nested alt fragments is a different diagram trying to escape; that diagram is an activity diagram, where branching is the native idiom.

Variants and trade-offs#

A few decisions recur each time you draw a sequence diagram in an interview.

How many lifelines. A meaningful flow usually has three to six. Two is suspicious — the flow probably had more participants and you missed one. Eight or more is suspicious in the opposite direction — the flow probably has sub-flows that deserve their own diagrams (linked via `ref` fragments).

Actor on the leftmost lifeline. Always. The flow originates with the user or external system; putting them on the left is convention and makes the diagram readable left-to-right.

Synchronous arrow shape. A filled solid arrowhead for synchronous (`caller waits`); an open arrowhead with a dashed line for return; an open arrowhead with a solid line for asynchronous one-way messages. Confusing return arrows with async arrows is a recurring error.

Whether to draw activations. Optional but recommended. In hand-drawn diagrams, eliding them is fine; in published diagrams, they make stack depth visible. Pick a convention at the start and stick with it.

When to use creation messages. A new X(...) message ends at the lifeline’s box, not below it, to signal the object did not exist before this message. Useful when the timing of creation matters (a Ticket is created mid-flow, not pre-existing); skip when the lifeline is for an object that already exists.

Sequence diagram. One flow, time-ordered, one diagram per use case. Good for narrating a single happy path plus its main alternative. Stay below ~15 messages per diagram for legibility.

Activity diagram. Workflow with multiple branches and multiple actors. Good when the control flow itself is the story. Reach for it when sequence-diagram alt fragments stack three deep.

When this is asked in interviews#

Sequence diagrams are usually asked second, after the class diagram is on the board. The interviewer’s most common cue: “Walk me through what happens when a driver parks.” That sentence is a request for a sequence diagram, even if they did not name it. Three patterns interviewers reward.

Draw lifelines for participants you have already named. If the class diagram has ParkingLot, Floor, ParkingSpot, and Ticket, those four are the candidate lifelines plus the actor and any boundary object (gate, controller, web layer). Inventing a new lifeline mid-flow is a signal you missed an entity earlier — own it: “I realise I should have had a Gate on the class diagram; let me add it as a lifeline here and I’ll patch the class diagram afterward.”

Narrate as you draw. The diagram is a score for your narration. “The driver hands the gate the vehicle. The gate asks the lot to park it. The lot iterates floors, asking each for a free spot. The floor checks each of its spots until one fits. The lot creates a new ticket, assigns the spot to it, and returns the ticket back up.” Each sentence corresponds to one arrow. If you cannot keep them in sync, slow the diagram down, not the narration.

Show the failure path next. As soon as the happy path is complete, the interviewer often asks “what if it fails?” Having a second sequence diagram ready for the most common failure (no spot available, payment declined) earns time and signals you have thought about errors. The simplest representation is the alt fragment described above; the cleaner one for a complex failure is a second diagram.

Common interviewer probes the sequence diagram makes easy to answer: “Who creates the Ticket?” (The arrow ends at the Ticket lifeline — that lifeline’s creator is the answer.) “Does the gate wait for the lot to respond?” (Filled arrowhead means yes.) “What if two cars arrive at once?” (The diagram is single-threaded; mention coarse synchronisation or per-floor locks as the answer.)

Search ESC

Keyboard shortcuts

Shortcuts are disabled while typing in inputs.