Sequence Diagrams

Introduction

Sequence diagrams show object interactions over time — the perfect follow-up after a class diagram when the interviewer says 'walk me through parking a car.'

Vertical lifelines represent objects; horizontal arrows are messages. Order matters: validate, allocate, persist, respond. Sequence diagrams expose missing classes (who issues the ticket?) faster than staring at boxes.

Practice one happy path and one failure path per LLD problem.

Understanding the topic

Key concepts

• Lifeline: object instance over time.
• Synchronous call: solid arrow; return: dashed.
• Activation bar: object actively processing.
• alt/opt frames for conditionals and loops.
• Self-call for internal private method.
• Actor stick figure for external user or system.

sequenceDiagram
  Client->>ParkingLot: park(vehicle)
  ParkingLot->>SpotFinder: findAvailable(type)
  SpotFinder-->>ParkingLot: spot
  ParkingLot->>Ticket: issue()

Step-by-step explanation

1. Place actors and objects left-to-right by initiation order.
2. Draw messages top-to-bottom chronologically.
3. Show return values when they drive next step.
4. Use alt block for insufficient balance / full lot.
5. Number messages if explaining complex flow.
6. Stop when reaching stable end state.

Syntax reference

Sequence diagram text notation:

• Solid arrow = call; dashed = return.
• Add alt/else for failure branches.

actor User
participant Controller
participant Service
participant Repository

User -> Controller: withdraw(amount)
Controller -> Service: withdraw(account, amount)
Service -> Repository: save(txn)
Repository --> Service: ok
Service --> Controller: Result
Controller --> User: cash + receipt

Informative example

ATM withdraw flow matching sequence messages:

public final class AtmController {
    private final CardReader cards;
    private final AtmService service;

    public AtmController(CardReader cards, AtmService service) {
        this.cards = cards;
        this.service = service;
    }

    public Result handleWithdraw(String cardToken, long cents) {
        Account account = cards.authenticate(cardToken);
        return service.withdraw(account, Money.ofCents(cents));
    }
}

Sequence: User -> AtmController -> CardReader -> AtmService -> CashDispenser — each arrow is one message.

Real-world use

Real-world applications

• Explaining checkout, transfer, and booking flows.
• Finding missing collaborator during design.
• Documenting API orchestration in RFCs.

Best practices

• One diagram per primary use case.
• Name messages after methods you will implement.
• Show failure rollback path for transactional flows.
• Do not include every private helper call.
• Reference sequence numbers when coding aloud.

Common mistakes

• Random object order — hard to follow.
• Skipping return messages that carry data.
• Modeling every loop iteration instead of one representative.
• Objects that never receive messages (remove from diagram).

Advanced interview questions

Summary

Sequence diagrams show temporal object interactions. Draw after class diagram for core flows. Use alt frames for success and failure paths. Message names should match Java methods. Keep diagrams readable — omit trivial internals.