Interview Forge

REQUIREMENTS & MODELING / OBJECT DESIGN BRIEF

Sequence diagrams

A sequence diagram shows how objects interact over time for one scenario: vertical lifelines for each participant and horizontal arrows for messages in order, including return values, conditions (alt), and loops.

IntermediatePhase 03 / Topic 5 of 8ResponsibilitiesCollaborationsExtensibility
01

Overview

A sequence diagram shows how objects interact over time for one scenario: vertical lifelines for each participant and horizontal arrows for messages in order, including return values, conditions (alt), and loops. Where class diagrams show structure, sequence diagrams show behavior.

In interviews, sketching the sequence of the main use case (for example 'book a seat' or 'request an elevator') proves your classes actually collaborate correctly: every message must be a method on the receiver, and responsibilities that nobody handles become obvious.

A movie script

Characters are listed across the top, and the script shows who says what to whom, in order. Reading it top to bottom tells the story of one scene.

02

When to use it

  • Validating the design against the main use case.
  • Explaining complex interactions (payment flows, callbacks).
  • Finding missing methods or misplaced responsibilities.
03

Where it shows up in interviews

Interaction validation

Recognize it when: 'walk me through what happens when...'

  • Design a movie ticket system
  • Design an elevator system
  • Design an ATM
04

Where it is used in real software

Mermaid sequenceDiagram

Common in GitHub docs and design docs to describe API flows.

OAuth and payment docs

Providers like Stripe and Auth0 document flows with sequence diagrams.

Distributed tracing

Trace waterfalls are runtime sequence diagrams of real requests.

05

Key terms

Lifeline
A participant's timeline.
Message
A call from one participant to another.
Activation
Period a participant is executing.
alt / opt / loop
Conditional, optional, and repeated fragments.
Async message
Open arrowhead; sender does not wait.
06

How it works, step by step

  1. 1
    Pick one scenario

    The main use case.

  2. 2
    List participants left to right

    Actor, controller, service, entities, external systems.

  3. 3
    Draw messages in order

    Each must be a method on the receiver.

  4. 4
    Add alternatives

    alt for failure paths like payment declined.

  5. 5
    Check responsibilities

    Is any object doing too much? Is data coming from the right owner?

Book a movie seat
Step 1 / 4
User
BookingService
Show
SeatLock
Payment

STEP 1User calls book(showId, ['A5', 'A6']).

07

What the diagram reveals

Reviewing the booking sequence

Step 1 / 4
ObservationDesign fix
Controller calls Seat.status directlyMove availability check into Show
No release on payment failureAdd alt branch with SeatLock.release
BookingService formats emailsDelegate to Notifier
Two users hold the same seatSeatLock.hold must be atomic

NOWObservation: Controller calls Seat.status directly | Design fix: Move availability check into Show

A sequence diagram is a cheap test of the design before writing code.

08

Implementation

sequenceDiagram  actor U as User  participant B as BookingService  participant L as SeatLock  participant P as PaymentGateway  participant S as Show  U->>B: book(showId, seats)  B->>L: hold(showId, seats, 10m)  alt seats already held    L-->>B: false    B-->>U: SeatUnavailable  else held    B->>P: charge(user, amount)    alt declined      B->>L: release(showId, seats)      B-->>U: PaymentFailed    else paid      B->>S: confirm(seats, user)      B-->>U: Booking    end  end
09

Complexity and performance

Participants4-7

Beyond that, split the scenario.

Scenarios to draw1-2

Main flow plus one failure.

10

Trade-offs

Clarity vs completeness

One diagram per scenario is clear; cramming every branch makes it unreadable.

Maintenance

Detailed diagrams go stale; keep them for key flows.

11

Variants and related techniques

Communication diagrams

Same messages arranged by object links rather than time.

Activity diagrams

Flowchart of steps and decisions without participants.

12

Common mistakes

  • Messages to objects that do not have that method.

    Fix: Update the class diagram or reassign responsibility.

  • The controller doing all the work.

    Fix: Delegate to domain objects; watch for a 'fan' of arrows from one lifeline.

13

Interview questions

Why draw a sequence diagram in an LLD interview?

It validates that classes collaborate correctly for the main use case, exposes missing methods and misplaced responsibilities, and communicates failure handling clearly.

How do you show error handling?

With alt fragments for alternative outcomes, showing compensations like releasing held seats when payment fails.

14

Practice problems

ProblemDifficultyWhat it trains
Sequence diagram for an elevator requestMediumController and scheduling.
Sequence diagram for Splitwise settle upMediumBalances update.