ATM Machine System – Low Level Design Interview Practice
Practise the ATM Machine System low level design problem the way an LLD round actually runs. You are asked for requirements first, then a class model, and then to extend the design when a new requirement lands part way through – the follow-up that separates a design that was memorised from one that was understood.
The round checks the things interviewers grade: whether your classes carry single responsibilities, whether you reached for a design pattern or reinvented one, whether the design absorbs a new requirement without rewriting what exists, and whether you can explain a trade-off out loud. Feedback covers class modelling, SOLID principles, use of patterns, extensibility and communication.
What this question is really testing
State plus cash dispensing. The transaction states are the obvious half; the note-breakdown and the partial-failure question are where the marks are.
Requirements to establish first
- Authenticate by card and PIN, with a limit on attempts.
- Offer balance enquiry, withdrawal, deposit and mini statement.
- Dispense a requested amount as a combination of the notes the machine holds.
- Refuse a withdrawal that exceeds the balance, the daily limit, or the machine's cash.
- Return the card and reset to idle at the end of every session, including on error.
Core classes
- ATM – Holds the current state and the cash dispenser. Delegates every operation.
- ATMState – Idle, CardInserted, Authenticated, DispensingCash, OutOfService.
- Card / Account – The card identifies; the account holds the balance. They are not the same object, and a card may map to several accounts.
- Transaction – Abstract, with Withdrawal, Deposit, BalanceEnquiry subclasses - each with its own validation.
- CashDispenser – Note inventory and the breakdown decision.
- NoteDispenseChain – 2000s, then 500s, then 100s - each handler taking what it can and passing the remainder on.
Design patterns that apply
- State – PIN entry is only legal after a card is inserted, and dispensing only after authentication. The pattern makes the illegal ordering unreachable.
- Chain of Responsibility – Note dispensing, and the cleanest real use of the pattern in this set: each denomination handler takes what it can and delegates the remainder.
- Factory – Transaction creation from a menu selection.
Follow-up questions to expect
- The account is debited and the dispenser jams. What does your design do, and when was the debit written?
- A customer asks for an amount the machine cannot make from its notes. Where is that refused, and before or after the balance check?
- Add a daily withdrawal limit across ATMs. Is that on Card, Account, or neither?
Where candidates lose marks
- Debiting before dispensing with no compensating action, which the first follow-up is designed to find.
- Greedy note selection presented as always optimal. It is not, for arbitrary denominations.
- PIN validation inside ATM rather than behind the bank service, which puts a secret in the wrong class.