Skip to content

ATM Low-Level Design Master Guide

Version 1.0

This guide is designed as a compact interview reference (15--20 pages) that teaches the thinking process behind designing an ATM system rather than just presenting a solution.

1. Problem Understanding

Functional Requirements

  • Authenticate a user using ATM card and PIN.
  • Allow cash withdrawal.
  • Allow balance inquiry.
  • Print receipt.
  • End the session.
  • Handle invalid PIN and card.

Non-Functional Requirements

  • Extensible for new transaction types.
  • Easy to maintain.
  • Follows SOLID principles.
  • Clear separation of responsibilities.

Clarifying Questions

  • Are we supporting only debit cards?
  • Is deposit required?
  • Should multiple banks be supported?
  • Is cash refill in scope?

2. Design Thinking Process

Whenever you see an LLD problem, never jump into coding.

Follow this order:

  1. Read the problem.
  2. Identify candidate objects.
  3. Classify every object.
  4. Assign responsibilities.
  5. Identify relationships.
  6. Choose design patterns.
  7. Draw class diagram.
  8. Implement code.
  9. Discuss trade-offs and extensions.

3. Candidate Objects

Object Category Why?

ATM Controller Coordinates the session User Entity Represents customer Card Entity Banking credential Account Entity Stores account data Transaction Entity Represents a banking operation CardReader Service Reads card BankService Service Banking operations CashDispenser Service Dispenses notes ReceiptPrinter Service Prints receipt ATMState State Object Represents current ATM state

4. Responsibilities

ATM

Purpose: Coordinate an ATM session.

Owns: - Current session - Current card - Current state

Knows: - CardReader - Transaction - CashDispenser - ReceiptPrinter

Card

Purpose: Represents the customer's banking credential.

Owns: - Card Number - Expiry - Status

Knows: - Account

Account

Purpose: Represents customer's bank account.

Owns: - Account Number - Balance - Status

Knows: - Transactions

Transaction

Purpose: Represents a banking transaction.

Owns: - Amount - Status - Timestamp - Type

Knows: - Account - BankService

5. Relationships

ATM ---- Transaction : Association

Card ---- Account : Association

ATM ---- ATMState : Composition

ATM ---- CardReader : Composition

ATM ---- CashDispenser : Composition

Transaction ---- BankService : Association

Avoid inheritance unless there is a genuine "is-a" relationship.

6. Suggested Class Diagram

                +----------------+
                |      ATM       |
                +----------------+
                | state          |
                | currentCard    |
                +----------------+
                   |    |     |
                   |    |     |
                   v    v     v
             CardReader  Transaction  CashDispenser
                         |
                         v
                    BankService

Card ---------> Account

7. Design Patterns

State Pattern

Use for ATM states: - Idle - Card Inserted - PIN Verified - Transaction

Benefits: - Removes large switch statements. - Easy to extend.

Strategy Pattern

Use for transactions.

WithdrawalStrategy

DepositStrategy

BalanceInquiryStrategy

Benefits: - Add new transaction without modifying existing code.

Factory Pattern

Use to create appropriate transaction object.

8. High-Level Java Structure

ATM
Card
Account

abstract Transaction
    WithdrawalTransaction
    DepositTransaction
    BalanceInquiryTransaction

ATMState
    IdleState
    CardInsertedState
    PinVerifiedState

CardReader
CashDispenser
ReceiptPrinter
BankService

9. Typical Interview Questions

Why State Pattern?

Why not switch-case?

Why is Transaction an Entity?

Why composition instead of inheritance?

How would you support UPI?

How would you support multiple banks?

10. Common Mistakes

  • Thinking about execution flow before objects.
  • Mixing responsibilities with methods.
  • Using inheritance everywhere.
  • Making controller perform business logic.
  • Ignoring extensibility.

11. Final Checklist

Before coding:

  • [ ] Requirements understood
  • [ ] Objects identified
  • [ ] Categories assigned
  • [ ] Responsibilities defined
  • [ ] Relationships justified
  • [ ] Design patterns selected
  • [ ] Class diagram drawn
  • [ ] APIs identified
  • [ ] Trade-offs discussed

Next Improvements

Future versions of this guide will include:

  • Complete UML
  • Full Java implementation
  • Sequence diagrams
  • Extensions
  • Production considerations
  • Mock interview discussion