Sequence Diagrams

A class diagram shows what objects exist and how they relate; a sequence diagram shows what happens when they interact. It adds time — reading top to bottom — so you can trace exactly which object calls which method, in which order, and what flows back. When explaining a multi-step flow, a sequence diagram makes the coordination between participants explicit.

Lifelines, messages, and activations

Every participant in a sequence diagram gets a vertical line called a lifeline. Horizontal arrows between lifelines represent messages (method calls). A thin rectangle on a lifeline marks an activation — the period during which that object is actively doing work. A dashed return arrow carries the result back to the caller once the work is done.

The notation is intentionally minimal. You do not need to capture every field or every branching condition at a whiteboard. Three or four participants with the happy-path messages tell the interviewer how the system coordinates.

A checkout flow

Consider a web checkout: the Customer adds items to a Cart, then triggers payment. The Cart delegates payment to a PaymentGateway, and on success it asks the OrderService to create a confirmed order. Four participants, a handful of messages, and the coordination is immediately visible.

Reading the diagram top to bottom: the customer adds an item and gets an acknowledgment. Calling checkout activates the Cart, which synchronously charges the payment gateway and waits for a result. On success it asks the OrderService to persist the order, then returns the confirmation to the customer. If the charge fails, Cart would return an error instead — a branch you can annotate with alt blocks when the interviewer probes error handling.

When the interviewer asks about error handling, extend the diagram with an alt block rather than rewriting it. The block makes both the success path and the failure path explicit without adding new participants.

Sequence diagrams versus prose for interactions

A class diagram cannot express ordering. Describing an interaction in text requires the reader to hold the sequence in memory while tracking which objects are involved. A sequence diagram externalizes both at once: the participants are named at the top, and the ordering is read down the page. The format is standard in design reviews and widely recognized.

Drawing the diagram also surfaces ambiguity. Adding the arrow from Cart to PaymentGateway raises the question "what does it return?" and forces a decision: does a failed charge throw an exception or return a result object? Resolving that question and documenting the choice on the diagram is part of the design work.