Overview
A use case describes how an actor interacts with the system to achieve a goal, step by step: the main success path plus alternate and failure paths. 'Withdraw cash' at an ATM: insert card, enter PIN, choose amount, dispense cash, print receipt; alternatives include wrong PIN, insufficient funds, and machine out of cash.
Use cases bridge requirements and design. Each step hints at a responsibility (who validates the PIN? who tracks cash?), and each alternate path is an edge case to handle. Walking through a use case against your class diagram is how you validate an LLD design.
The main steps make the dish; the notes say what to do if the sauce is too thick or you are out of an ingredient. Use cases include both.
When to use it
- After listing requirements, before designing classes.
- Discovering edge cases and error handling.
- Validating a design by tracing it end to end.
Where it shows up in interviews
Recognize it when: systems with clear user journeys.
- Design an ATM
- Design a movie ticket booking system
- Design a vending machine
Where it is used in real software
Show actors and the goals they pursue; common in enterprise requirements.
Fully dressed use cases with preconditions, main flow, extensions, and postconditions.
Playwright or Cypress tests often mirror primary use cases.
Key terms
- Actor
- Person or system with a goal.
- Main success scenario
- The happy path.
- Extension / alternate flow
- What happens when a step fails or varies.
- Precondition / postcondition
- State before / guaranteed state after.
How it works, step by step
- 1Name the goal
'Customer withdraws cash'.
- 2Write the main flow
5-9 numbered steps.
- 3Add extensions per step
3a. PIN wrong: retry up to 3 times, then retain card.
- 4Note pre/postconditions
Card valid before; account debited after.
- 5Map steps to objects
Each verb becomes a method on a responsible class.
STEP 1The card reader reads the card; the bank validates the PIN (3 attempts allowed).
Withdraw cash: steps and responsibilities
Mapping use case steps to classes
| Step | Extension | Responsible object |
|---|---|---|
| Read card | Card unreadable: eject | CardReader |
| Validate PIN | Wrong 3 times: retain card | BankService / Session |
| Check funds and limits | Insufficient: show message | BankService |
| Dispense notes | Machine short of notes: cancel and reverse | CashDispenser |
| Print receipt | Out of paper: offer screen receipt | ReceiptPrinter |
NOWStep: Read card | Extension: Card unreadable: eject | Responsible object: CardReader
Every extension becomes a tested branch in the design.
Implementation
// A use case as an application service; each extension is an explicit branchclass WithdrawCash { constructor(private bank: BankService, private dispenser: CashDispenser, private printer: ReceiptPrinter) {} async execute(session: AtmSession, amount: number): Promise<string> { if (!session.authenticated) throw new Error("Not authenticated"); if (!this.dispenser.canDispense(amount)) return "Amount not available in this ATM"; // extension const hold = await this.bank.hold(session.accountId, amount); if (!hold.ok) return "Insufficient funds"; // extension try { this.dispenser.dispense(amount); await this.bank.commit(hold.id); } catch { await this.bank.release(hold.id); // extension: jam return "Unable to dispense, you were not charged"; } this.printer.tryPrint(`Withdrew ${amount}`); return "Please take your cash"; }}Complexity and performance
Walk the most important.
Become edge-case handling.
Trade-offs
Fully dressed use cases are thorough but slow; in interviews, bullet the main flow and key extensions.
Use cases describe behavior, not classes; combine with entity identification.
Variants and related techniques
Lightweight goal statements with acceptance criteria.
Show a use case as messages between objects.
Common mistakes
- Only designing the happy path.
Fix: Interviewers probe failures; list extensions early.
- UI details in use cases.
Fix: Describe intent ('selects amount'), not button colors.
Interview questions
How do use cases help in LLD interviews?
They reveal responsibilities and collaborators step by step, expose edge cases through alternate flows, and let you validate the class design by tracing each step.
What are the key extensions for booking a movie seat?
Seat taken by someone else during selection, hold expiring before payment, payment failure, show cancelled, and user abandoning checkout.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Write 'return a book' with extensions | Easy | Alternate flows. |
| Use cases for Splitwise add expense and settle up | Medium | Mapping to classes. |