Design ATM
Last Updated: February 7, 2026
What is an ATM?
An ATM (Automated Teller Machine) is a self-service banking machine that allows users to perform basic financial transactions such as withdrawing cash and checking account balances using a debit or credit card and a secure PIN, without needing to visit a bank branch.
Loading simulation...
They interface with backend banking systems to verify account details, authenticate users, and update balances in real-time.
In this chapter, we will explore the low-level design of ATM in detail.
Lets start by clarifying the requirements:
1. Clarifying Requirements
Before starting the design, it's important to ask thoughtful questions to uncover hidden assumptions, clarify ambiguities, and define the system's scope more precisely.
Here is an example of how a discussion between the candidate and the interviewer might unfold:
Candidate: "What types of transactions should the ATM support?"
Interviewer: "The ATM should support three transaction types: cash withdrawal, cash deposit, and balance inquiry."
Candidate: "How does the ATM authenticate users? Is it card-based with a PIN?
Interviewer: "Yes, standard card and PIN authentication. The user inserts a card, enters a PIN, and the system verifies it against a bank service. For this design, you can simulate the call to bank service"
Candidate: "What denominations should the ATM support for dispensing cash?"
Interviewer: "Let's support four denominations: $100, $50, $20, and $10 bills. The ATM should dispense using the largest bills first."
Candidate: "How should the ATM handle edge cases like insufficient funds in the user's account, or the ATM running out of cash?"
Interviewer: "Both should be handled gracefully with appropriate error messages. The ATM should check both the account balance and its own cash inventory before dispensing."
Candidate: "Do we need to take input from the user, or can we hardcode a sequence of operations?"
Interviewer: "You can hardcode a sequence of operations for the demo. No need for user input handling."
Candidate: "Should we enforce daily transaction or withdrawal limits per user?"
Interviewer: "Let’s skip that for now. Assume there are no limits on the number or amount of transactions per day."
After gathering the details, we can summarize the key system requirements.
1.1 Functional Requirements
- Authenticate users via card number and PIN
- Support three transaction types: withdrawal, deposit, and balance inquiry
- Dispense cash using the largest denominations first ($100, $50, $20, $10)
- Validate both account balance and ATM cash inventory before dispensing
- Track ATM state transitions (idle, card inserted, authenticated)
- Simulate bank operations (authentication, balance check, debit, credit) via an in-memory service
1.2 Non-Functional Requirements
- The design should follow object-oriented principles with clear separation of concerns
- The system should be modular and extensible to support new transaction types and denominations
- The code should be thread-safe for concurrent access
- The components should be testable in isolation
- Financial operations should follow validation-before-commit: always verify dispensability before debiting
After the requirements are clear, lets identify the core entities/objects we will have in our system.