Model key interactions

Overview

Step 5: walk the most important use cases through your objects, in order, as a sequence of method calls. This validates the class diagram: every call must be a method on the receiving class, data must come from its owner, and failure branches must have a clear handler.

In an interview, narrating 'the user calls BookingService.hold, which asks Show.hold, which checks each ShowSeat...' with a quick sequence sketch shows the design works end to end. It often reveals missing methods, misplaced responsibilities, and concurrency gaps before you write the full code.

When to use it

• After the class diagram, before or while coding.
• When the interviewer asks 'walk me through booking a ticket'.
• Debugging a design with unclear flows.

Where it shows up in interviews

Where it is used in real software

Key terms

Happy path

The main successful flow.

Failure branch

Alternative flow when a step fails.

Compensation

Undo earlier steps after a failure (release hold).

Atomic step

Must happen without interference (hold seats).

How it works, step by step

1. 1
   Pick 1-2 key use cases

   Book seats; cancel booking.

2. 2
   Write the call sequence

   Caller -> method -> callee.

3. 3
   Mark atomic sections

   Hold must be all-or-nothing and synchronized.

4. 4
   Add failure branches

   Seat taken, payment failed, hold expired.

5. 5
   Fix design gaps

   Add missing methods or move responsibilities.

Gaps found during the walkthrough

Reviewing the book-seats flow

Each gap became a small, targeted design change.

Implementation

1public Booking book(String userId, String showId, List<String> seatIds) {2    Show show = shows.get(showId);                                   // 1. load aggregate3    Hold hold = show.hold(seatIds, userId, clock.instant().plus(HOLD_TTL)); // 2. atomic hold (synchronized in Show)4    Money total = pricing.total(show, seatIds);                      // 3. pricing strategy5    boolean paid;6    try {7        paid = payments.charge(userId, total);                       // 4. external call outside any lock8    } catch (RuntimeException e) {9        show.release(hold);                                          // failure branch: compensate10        throw e;11    }12    if (!paid) { show.release(hold); throw new PaymentDeclinedException(); }13    show.confirm(hold, clock.instant());                             // 5. fails if hold expired14    Booking booking = new Booking(ids.next(), showId, userId, seatIds, total);15    bookings.save(booking);                                          // 6. persist16    notifier.bookingConfirmed(booking);                              // 7. side effect last17    return booking;18}

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Holding locks during payment calls.

  Fix: Lock only for state changes; call external systems outside.

• No compensation on failure.

  Fix: Release holds and reverse steps explicitly.

Interview questions

Practice problems