Loading low-level design…

Design an ATM - Low-Level Design | OneNoughtOne

00:00:00

Design an ATM

Intermediate

Design an object - oriented ATM system that supports card - based authentication, cash withdrawal with denomination management, deposits, and balance inquiries.

The system should use a state machine to manage the ATM lifecycle(idle → authentication → transaction selection → cash dispense → idle), implement a greedy denomination algorithm for cash dispensing, and support multiple account types(savings, checking with overdraft).

Core Use Cases

Card authentication

Insert card and validate PIN to access the account

Cash withdrawal

Withdraw a specified amount if balance and ATM cash are sufficient

Cash deposit

Deposit cash into the account

Balance inquiry

Check the current account balance

Cash dispensing with denominations

Dispense the requested amount using available bill denominations (greedy algorithm)

Transaction logging

Record every transaction with timestamp, type, amount, and status

Card ejection and session end

Eject the card and reset the ATM to idle state

Constraints

PIN must be validated before any transaction is allowed
Withdrawal cannot exceed account balance (or overdraft limit for checking accounts)
ATM cannot dispense more cash than it physically holds
Cash must be dispensed using the fewest bills possible (greedy by largest denomination)
Maximum 3 PIN attempts before the card is retained
Each session handles one card at a time

Assumptions

Simplified bank — accounts stored in-memory on the ATM for simulation
No inter-bank network communication
Single-threaded (one user at a time)
Denominations are standard bills ($100, $50, $20, $10, $5, $1)

In Scope

Card insertion and PIN authentication
Withdrawal, deposit, and balance inquiry transactions
Cash dispenser with denomination management
State-based ATM lifecycle (idle → auth → transaction → dispense → idle)
Transaction history logging

Out of Scope

Inter-bank networking and authorization
Receipt printing
Cheque deposits
Multi-language UI
Physical hardware control (card reader, bill acceptor motor)

Approach Guide(Click to expand each section)

Before diving into code, clarify the use cases and edge cases. Understanding the problem deeply leads to better class design.

List Core Use Cases

Identify the primary actions users will perform. For a parking lot: park vehicle, exit vehicle, check availability. Each becomes a method.

Identify Actors

Who interacts with the system? Customers, admins, automated systems? Each actor type may need different interfaces.

Clarify Constraints

What are the limits? Max vehicles, supported vehicle types, payment methods. Constraints drive your data structures.

Ask About Edge Cases

What happens on overflow? Concurrent access? Payment failures? Thinking about edge cases reveals hidden complexity.

Follow-up Questions(Questions an interviewer might ask)

💡 Draw UML class diagrams, sequence diagrams, or any design visualizations. Submit from the Code tab.

Loading canvas...

Loading LLD design...

00:00:00

Design an ATM

Intermediate

Design an object - oriented ATM system that supports card - based authentication, cash withdrawal with denomination management, deposits, and balance inquiries.

Core Use Cases

Card authentication

Insert card and validate PIN to access the account

Cash withdrawal

Withdraw a specified amount if balance and ATM cash are sufficient

Cash deposit

Deposit cash into the account

Balance inquiry

Check the current account balance

Cash dispensing with denominations

Dispense the requested amount using available bill denominations (greedy algorithm)

Transaction logging

Record every transaction with timestamp, type, amount, and status

Card ejection and session end

Eject the card and reset the ATM to idle state

Constraints

PIN must be validated before any transaction is allowed
Withdrawal cannot exceed account balance (or overdraft limit for checking accounts)
ATM cannot dispense more cash than it physically holds
Cash must be dispensed using the fewest bills possible (greedy by largest denomination)
Maximum 3 PIN attempts before the card is retained
Each session handles one card at a time

Assumptions

Simplified bank — accounts stored in-memory on the ATM for simulation
No inter-bank network communication
Single-threaded (one user at a time)
Denominations are standard bills ($100, $50, $20, $10, $5, $1)

In Scope

Card insertion and PIN authentication
Withdrawal, deposit, and balance inquiry transactions
Cash dispenser with denomination management
State-based ATM lifecycle (idle → auth → transaction → dispense → idle)
Transaction history logging

Out of Scope

Inter-bank networking and authorization
Receipt printing
Cheque deposits
Multi-language UI
Physical hardware control (card reader, bill acceptor motor)

Approach Guide(Click to expand each section)

Before diving into code, clarify the use cases and edge cases. Understanding the problem deeply leads to better class design.

List Core Use Cases

Identify the primary actions users will perform. For a parking lot: park vehicle, exit vehicle, check availability. Each becomes a method.

Identify Actors

Who interacts with the system? Customers, admins, automated systems? Each actor type may need different interfaces.

Clarify Constraints

What are the limits? Max vehicles, supported vehicle types, payment methods. Constraints drive your data structures.

Ask About Edge Cases

What happens on overflow? Concurrent access? Payment failures? Thinking about edge cases reveals hidden complexity.

Follow-up Questions(Questions an interviewer might ask)

💡 Draw UML class diagrams, sequence diagrams, or any design visualizations. Submit from the Code tab.

Loading canvas...

Design an ATM

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Follow-up Questions(Questions an interviewer might ask)

Explore the full editorial.

Sign in to view submissions

Design an ATM

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Follow-up Questions(Questions an interviewer might ask)

Explore the full editorial.

Sign in to view submissions

Design an ATM

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Gather Requirements~3 min

Identify Classes & Entities~4 min

Define Relationships~3 min

Apply Design Patterns~4 min

Apply SOLID Principles~3 min

Code Organization~2 min

Follow-up Questions(Questions an interviewer might ask)

1How would you support multiple account types (savings, checking) linked to a single card?

2How would you handle the case where the ATM cannot make exact change?

3How would you add fund transfer between accounts?

4How would you implement daily withdrawal limits?

Key Topics

Asked At

Explore the full editorial.

Sign in to view submissions

Design an ATM

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Gather Requirements~3 min

Identify Classes & Entities~4 min

Define Relationships~3 min

Apply Design Patterns~4 min

Apply SOLID Principles~3 min

Code Organization~2 min

Follow-up Questions(Questions an interviewer might ask)

1How would you support multiple account types (savings, checking) linked to a single card?

2How would you handle the case where the ATM cannot make exact change?

3How would you add fund transfer between accounts?

4How would you implement daily withdrawal limits?

Key Topics

Asked At

Explore the full editorial.

Sign in to view submissions