Why sequence diagrams exist
A class diagram answers “what are the parts and how are they wired?” It is a static snapshot: classes, fields, methods, and the associations between them. It says nothing about time.
A sequence diagram answers a different question: “who calls whom, in what order, to satisfy one specific scenario?” It is a dynamic view. It takes a single use case — “user checks out a cart,” “ride request gets matched to a driver,” “a payment is captured” — and lays out the exact chain of method calls between objects, top to bottom in time.
This distinction is the whole reason the diagram exists, and it is the single most common thing interviewers are probing when they say “walk me through what happens when…”. They are not asking for your class list again. They are asking you to prove your objects actually collaborate to do the job.
Class diagram = the cast list and their relationships. Sequence diagram = one scene from the screenplay, with stage directions for who speaks when.
A sequence diagram models one scenario, one path of execution. If you find yourself trying to cram every branch of every use case into a single diagram, you are doing it wrong — draw the happy path, then add a second diagram (or an alt fragment) for the important alternate flow.
The core notation
Every sequence diagram is built from a small, fixed vocabulary. Learn these six elements and you can read or draw any sequence diagram.
Lifelines
A lifeline is one participant in the scenario — usually an object instance, sometimes an actor (the human/external system). It is drawn as a box at the top with a dashed vertical line dropping down from it. That dashed line is time: top is “now,” lower is “later.”
Name lifelines as instance : Class (or just :Class for an anonymous instance, or Actor for a human). The colon-prefixed style is the giveaway that you are talking about a runtime object, not a class.
+----------+ +--------------+ +------------------+
| :User | | :OrderService| | :PaymentGateway |
+----+-----+ +------+-------+ +--------+---------+
: : :
: : : (time flows down)
: : :
v v vActivation bars
An activation bar (a.k.a. execution occurrence) is the thin rectangle drawn on top of a lifeline to show “this object is currently doing work / has an active stack frame.” It starts when a message arrives and ends when the object returns.
Nested activations stack: if OrderService calls PaymentGateway, the OrderService bar stays active (it’s blocked, waiting) while a new bar appears on PaymentGateway.
:User :OrderService :PaymentGateway
: : :
: placeOrder() : :
|==================># :
| # charge(amount) :
| #======================>#
| # # <- both active:
| #<- - - - - - - - - - - # Service is blocked
| # paymentId : waiting on Gateway
|<- - - - - - - - - # :
| orderId : :Synchronous messages
A synchronous message is a normal blocking method call: the caller stops and waits for the result. Drawn with a solid line and a solid (filled) arrowhead. This is 95% of what you draw in an LLD interview, because most code is plain method calls.
By convention, an
awaited asynchronous call is also drawn as a synchronous (filled-arrowhead) message — from the sequence’s point of view the caller suspends until the result returns, so the call ordering is exactly that of a blocking call. The “async arrow” is reserved for the case where the caller does not wait.
Return messages
A return message is the value coming back from a synchronous call. Drawn with a dashed line and an open arrowhead (<- - -). You do not have to draw a return for every call — only draw returns that carry information you want to highlight (the order id, the boolean result, the matched driver). Omitting trivial returns keeps the diagram readable.
Asynchronous messages
An asynchronous message is fire-and-forget: the caller does not block, it keeps executing immediately. Drawn with a solid line and an open (line/stick) arrowhead (a thin >, no filled triangle). Use it for: publishing an event to a queue, sending a notification, kicking off a background job, an await-less promise, posting to another thread.
The visual difference is subtle but interview-relevant: filled arrowhead = “I’ll wait” (sync). Open/stick arrowhead = “I’m not waiting” (async). If you tell the interviewer “this notification is sent asynchronously so checkout isn’t blocked on email delivery,” draw it with the open arrowhead to back up the claim.
A pedantic note worth knowing: the open/stick arrowhead for async is the UML 2.x convention. UML 1.x (and some older tools) drew asynchronous messages with a half/single-barbed arrowhead instead. If an interviewer draws a half-arrow, they almost certainly mean async — don’t get derailed; both render the same idea. Just be consistent within your own diagram.
Self-messages and object creation
A self-message (an object calling its own private method) loops back onto the same lifeline with a small nested activation bar. Object creation is a message arrow pointing at the box of a newly-created lifeline that starts lower down (born mid-scenario). Deletion is marked with an X at the bottom of the lifeline.
:OrderService
#
#--+ validate() <- self message, nested activation
#<-+
#
#-------------> +----------+
# <<create>> | :Invoice | <- created mid-scenario
# +----+-----+A complete worked example: checkout
Let’s model one scenario: a user checks out a cart. Happy path. This is the kind of diagram you’d whiteboard in 3-4 minutes.
:User :CartService :InventoryService :PaymentGateway :EventBus
: : : : :
| checkout(cart): : : :
|==============># : : :
| # reserve(items) : : :
| #=================># : :
| #<- - - - - - - - -# reserved=true : :
| # : : :
| # charge(total) : : :
| #====================================> # :
| #<- - - - - - - - - - - - - - - - - - - # paymentId :
| # : : :
| # publish(OrderPlaced) (async, fire-and-forget) :
| #------------------------------------------------------> :
| # (does NOT wait) :
|<- - - - - - - # : : :
| orderId : : : :
X : : : :Read it top-to-bottom: User calls checkout (sync, filled arrow). CartService synchronously reserves inventory and waits for the result, then synchronously charges payment and waits, then asynchronously publishes OrderPlaced to the event bus (open arrowhead — note there’s no return and the CartService bar continues immediately). Finally it returns orderId to the user.
The code below produces this call ordering. It closely mirrors the diagram — each await/blocking call is a sync arrow + return, the un-awaited publish is an async arrow with no return — but read the caveats after it: the three async mechanisms are not semantically equivalent, and the diagram deliberately abstracts over those differences.
class CartService {
constructor(
private inventory: InventoryService,
private payments: PaymentGateway,
private bus: EventBus,
) {}
async checkout(cart: Cart): Promise<string> {
// synchronous (awaited) call -- caller blocks
const reserved = await this.inventory.reserve(cart.items);
if (!reserved) throw new Error("Out of stock");
// synchronous (awaited) call -- caller blocks
const paymentId = await this.payments.charge(cart.total);
// asynchronous -- fire and forget.
// WARNING: 'void promise' SILENTLY SWALLOWS any rejection.
// Attach .catch() (or route through a durable queue) so a failed
// publish is surfaced, not lost:
this.bus
.publish(new OrderPlaced(cart.id, paymentId))
.catch(err => logger.error("publish failed", err));
return cart.id; // return message back to User
}
}The classic std::thread([this]{ bus_.publish(...); }).detach(); is an anti-pattern, not a best practice. A detached thread captures this (and therefore the reference member bus_). If the CartService instance — or the EventBus it references — is destroyed before the detached thread runs publish(), this/bus_ dangle: use-after-free, undefined behavior. It “works” in toy code only because the object happens to outlive the thread. A strict SSE interviewer will flag it on sight. Safer options: post a self-contained job (copying needed state by value) to a thread pool / executor that owns its workers; use std::async and retain the returned future; or push onto a real message broker that owns its own lifetime.
“Fire-and-forget” is clean on a diagram but treacherous in code. The async arrow drops the result/error edge — that is exactly why it has no return message, and exactly why error handling needs separate treatment. Across languages the same arrow hides very different machinery: TS void promise swallows rejections; an un-retained asyncio.create_task can be garbage-collected before it finishes and its exception surfaces only as a late warning (and it needs a running event loop); C++ .detach() spawns an unmanaged OS thread per call with no error propagation and no lifetime guarantee. Cooperative event-loop scheduling and thread-per-task detachment are not the same thing. Treat the single async arrow as an abstraction, and back it with retries / dead-letter / an outbox in real systems.
Combined fragments: loops, alt, opt, par
Real scenarios have repetition and branching. UML wraps these in combined fragments — labelled boxes drawn around a region of the diagram. The label in the top-left corner is the operator. The five you reach for most often:
| Operator | Meaning | Use it for |
|---|---|---|
loop | Repeat the enclosed messages | ”for each item in cart”, retry N times |
alt | Mutually exclusive branches (if/else if/else) | success vs failure, role-based paths |
opt | Optional — runs if guard is true (just an if) | “if user is premium, apply discount” |
par | Parallel regions run concurrently | fan-out to multiple services at once |
ref | Reference another sequence diagram | hide a sub-flow you diagrammed elsewhere |
That list is a curation of the high-frequency operators. UML defines several more you should at least know exist: break (if its guard holds, run the fragment and then abandon the rest of the enclosing interaction — handy for early-exit / error short-circuits), critical (a region that must not be interleaved with other messages — i.e. a mutual-exclusion / atomic section), plus seq, strict, and neg. Naming break or critical when relevant is a quiet senior signal.
Each branch/region is separated by a dashed horizontal divider, and a [guard] condition appears at the top of each.
loop + alt in ASCII
Here a MatchingService loops over nearby drivers and uses alt to handle accept vs decline:
:Rider :MatchingService :Driver
: : :
| requestRide() : :
|================># :
| # findNearbyDrivers() :
| #--+ :
| #<-+ [d1, d2, d3] :
| +===============#==========================================+
| | loop [for each driver until accepted] : |
| | # offerRide() : |
| | #=========================># |
| +-- alt --------#- [accepts] --------------#-------------+
| | #<- - - - - - - - - - - - -# accept |
| | # (break out of loop) : |
| +- - - - - - - -#- [declines] - - - - - - -#- - - - - - -+
| | #<- - - - - - - - - - - - -# decline |
| | # (continue loop) : |
| +===============#==========================================+
|<- - - - - - - - # rideConfirmed :
| matchResult : :You don’t need pretty box-drawing characters on a whiteboard — a plain rectangle with loop [...] and alt written inside is perfectly standard and graders expect it. The guards in [brackets] are the important part: they make the branching condition explicit.
Do not nest five fragments deep or draw eight lifelines. A sequence diagram that needs scrolling in two directions has failed at its one job: communication. If a scenario is genuinely that complex, split it — diagram the main flow, and use a ref fragment to point at sub-diagrams. Interviewers read “I’ll keep this focused on the happy path and call out the one important alternate branch” as a senior signal, not a lazy one.
When to reach for which diagram (interview decision guide)
This is the judgment the lesson is really about. In a 45-minute LLD round you have time for maybe 1-2 diagrams. Pick the right one.
Reach for a CLASS diagram when the interviewer cares about structure:
- “Design a parking lot / elevator / chess game” — they want your entities, inheritance, and relationships first.
- You need to show an inheritance hierarchy, an interface, or a design-pattern shape (Strategy, Factory, Observer wiring).
- The question is “how do these types relate?” / “what does the object model look like?”
Reach for a SEQUENCE diagram when the interviewer cares about behavior over time:
- The prompt is “walk me through what happens when a user does X.” This is the explicit trigger.
- You need to justify an async boundary (“checkout doesn’t block on email”), a retry/loop, or a multi-service collaboration where ordering matters.
- A race condition, deadlock, or ordering bug is on the table — sequence diagrams make “who holds the lock while who waits” visible in a way class diagrams cannot.
- You’re showing how a design pattern behaves at runtime (e.g., how an Observer notification actually propagates, or how a Chain of Responsibility passes the request along).
Strong default workflow in an LLD interview: draw the class diagram first to nail entities and relationships, then draw a sequence diagram for the single most interesting use case to prove the objects collaborate correctly. The two diagrams complement each other — the class diagram gives you the lifelines, the sequence diagram gives them their script.
The fastest way to score points: when the interviewer says “what happens when…”, immediately respond “let me sequence that out” and start a sequence diagram. You are matching the diagram type to the question type, which is exactly the meta-skill they’re grading. Reaching for a class diagram in response to a behavioral prompt — or vice versa — signals you’ve memorized notation without understanding what each view is for.
Cheat sheet to memorize
- Lifeline:
instance : Class, dashed line dropping down = time. - Activation bar: rectangle on the lifeline = active stack frame; nests while blocked.
- Sync message: solid line, filled arrowhead = “I wait.” (Also used for
awaited calls.) - Return: dashed line, open arrowhead — draw only the ones that matter.
- Async message: solid line, open/stick arrowhead (UML 2.x; half-arrow in legacy), no return = “I don’t wait.” Hides error/lifetime details — handle those separately.
- Fragments:
loop,alt,opt,par,ref(knowbreak/criticaltoo); always write the[guard]. - Rule: one scenario per diagram, happy path first, keep it small enough to read.