Problem statement
Design the object model and public APIs for the software that runs a single automated teller machine: the state machine that walks a customer through a session, the seam that talks to the bank, and the seam that drives the physical hardware. This is the controller inside one cabinet, not the bank's back-end.
Operating context. One machine, one customer at a time, driven by a single control thread. A session begins when a card is inserted and a PIN is entered; the machine authenticates against the bank, then offers balance inquiry, withdrawal, and deposit. A withdrawal must pick which notes to dispense from the cash cassettes (e.g. some mix of the available denominations) and can fail if the machine lacks the right notes even when the account has funds. Hardware is a set of peripherals — card reader, PIN pad, cash dispenser, deposit slot, screen, receipt printer — each of which can jam or go offline. The bank is a remote service reached over an unreliable link; a debit that is sent but whose reply is lost must not silently double-charge the customer.
Out of scope. The bank's core-banking ledger and fraud engine, the network/wire protocol and its encryption, the GUI toolkit and screen layouts, cash replenishment and armored-truck logistics, and multi-machine fleet management or remote monitoring. Model the in-cabinet object graph, not the systems around it.
What to produce. The class hierarchy (entities such as the session and the account handle; value objects such as money and a denomination; services such as the transaction handlers; and interfaces for the bank and each hardware peripheral), the public API each class exposes, and the explicit state transitions of a session (idle -> card read -> authenticating -> menu -> per-transaction -> ejecting). Be explicit about: how the session state machine forbids illegal steps (no dispense before auth), how the note-selection strategy is pluggable and reports when it cannot make the amount, how every hardware peripheral hides behind an interface so it can be faked in tests, and how an interrupted bank debit is reconciled so the customer is charged at most once.
Requirements
This assessment is a Premium feature.
The statement above is free to read. The functional and non-functional requirements, and the graded canvas that scores your design against them, come with Premium.
Topics
- System Design LLD
- Statemachine
- Oop Solid
- Patterns Strategy
- Concurrency Locks