Design an ATM

1Clarify the requirements#

Before I draw a single box, I ask questions. The interviewer is watching whether I scope the problem or just start coding.

• ATM is a trap because people over-build it into a banking system.
• I want to stay inside the machine, the metal box on the wall, not the bank behind it.
• Here is roughly how that conversation goes in my head.

What does the machine actually do? Pin down the happy path:

• A customer inserts a card and enters a PIN.
• They pick an operation: withdraw cash, deposit cash, check balance.
• On withdraw, the machine checks the account balance, checks it physically has enough cash, dispenses notes, and the card comes back.

Functional scope I will commit to:

• Authenticate a card plus PIN.
• Withdraw cash (the headline feature, so this is where I spend my code budget).
• Check balance.
• Deposit cash (I keep this light, one or two sentences).
• Eject the card and reset.

What I explicitly push out of scope:

• The bank's core ledger, fraud systems, the network protocol to the bank.
• Cheque deposits and multi-currency.
• I talk to the bank through a thin BankService interface and assume it is the source of truth for balances.
• I own the machine, not the bank. Saying this out loud in the first two minutes is half the battle: it tells the interviewer I know where the boundary is.

Non-functional things that actually matter here:

• Correctness over everything. Dispensing the wrong amount is a disaster. No double-dispense, ever.
• One session at a time. A physical ATM serves exactly one person at one moment. That simplifies concurrency a lot, and it is worth saying out loud because it changes my whole answer later.
• Fail safe. If anything goes wrong mid-transaction, the card comes out and no money moves unless the customer got the cash.

That last point drives the whole design. An ATM is really a state machine with a cash box bolted on.

2Identify the core entities#

Name the nouns, then justify each one. If I cannot justify a class, it does not exist yet. That discipline keeps me from drawing fifteen boxes I will never use.

• ATM is the top-level machine. It holds the current state and the hardware. It is the context in the State pattern, nothing more.
• ATMState is the heart of it. The machine behaves completely differently depending on whether a card is inserted, a PIN is pending, or an operation is selected. That is a State pattern begging to be used.
• Card carries the card number and a reference to the account. Dumb data holder, no logic.
• Account is a local view of balance and account number. The real truth lives at the bank, so this is mostly a handle I pass around.
• CashDispenser manages the physical note inventory and figures out which notes to hand out. This is the one genuinely algorithmic class.
• BankService is the boundary to the backend. Validate PIN, read balance, debit, credit. I keep it an interface so I can stub it in tests and so the state classes never know about the network.
• Transaction records what happened: type, amount, result. Useful for receipts and auditing, and a clean hook for the Observer follow-up.
• Screen / Keypad / CardReader are hardware I model thinly. I do not want the interviewer to think I forgot the physical side, but I also will not write a driver for a keypad.

The entity I lean on hardest is state. Let me show that.

3Class design#

The design splits into three groups.

• The state machine. An ATMState interface with one concrete class per screen the user can be on. Each state only allows the operations that make sense there. Try to withdraw before entering a PIN and IdleState just refuses. That is the whole point: illegal transitions become impossible instead of guarded by a pile of if checks that someone eventually forgets to update.
• The hardware and services. CashDispenser, CardReader, BankService. The ATM delegates to these. The dispenser owns the note-counting logic, the one genuinely algorithmic piece.
• The operations. Withdraw, deposit, balance. I model these as transactions so I get a uniform record and an easy place to hang a receipt.

Here is the class diagram.

The relationships are not decoration, they tell the interviewer what owns what:

• The ATM aggregates its current ATMState: the state object gets swapped as the user moves through the flow, so it is an aggregation, not a composition.
• The ATM composes the CashDispenser: it is born and dies with the machine.
• The bank is an association because it lives outside the machine entirely.

4Key implementation#

Write the parts that carry the design. Start with the state contract.

public interface ATMState {
    void insertCard(ATM atm, Card card);
    void enterPin(ATM atm, String pin);
    void selectWithdraw(ATM atm, double amount);
    void ejectCard(ATM atm);
}

Then a base class so each concrete state only overrides the moves that are legal for it. Everything else fails loudly, which is exactly what I want: a bug surfaces as an exception, not as a silent no-op.

public abstract class AbstractState implements ATMState {
    public void insertCard(ATM atm, Card card) { reject(); }
    public void enterPin(ATM atm, String pin)  { reject(); }
    public void selectWithdraw(ATM atm, double amount) { reject(); }
    public void ejectCard(ATM atm) { reject(); }

    private void reject() {
        throw new IllegalStateException("Operation not allowed in this state");
    }
}

IdleState is the resting state. The only legal move is inserting a card.

public class IdleState extends AbstractState {
    @Override
    public void insertCard(ATM atm, Card card) {
        atm.setCurrentCard(card);
        atm.setState(new HasCardState());
        atm.getScreen().show("Enter your PIN");
    }
}

HasCardState takes a PIN and asks the bank. Three wrong tries and we eat the card. Success moves us to authenticated.

public class HasCardState extends AbstractState {
    private int attempts = 0;

    @Override
    public void enterPin(ATM atm, String pin) {
        Card card = atm.getCurrentCard();
        if (atm.getBank().validatePin(card, pin)) {
            atm.setState(new AuthenticatedState());
            atm.getScreen().show("Select a transaction");
            return;
        }
        attempts++;
        if (attempts >= 3) {
            atm.getScreen().show("Card retained. Contact your bank.");
            atm.retainCard();
            atm.setState(new IdleState());
        } else {
            atm.getScreen().show("Wrong PIN. Try again.");
        }
    }

    @Override
    public void ejectCard(ATM atm) {
        atm.releaseCard();
        atm.setState(new IdleState());
    }
}

AuthenticatedState is where withdraw lives, and the ordering is the whole point. Check the account has the money, check the machine has the notes, debit at the bank, then and only then dispense. Every one of those four steps is in that order for a reason, and I say each reason aloud as I write it.

public class AuthenticatedState extends AbstractState {
    @Override
    public void selectWithdraw(ATM atm, double amount) {
        Account account = atm.getCurrentCard().getAccount();
        BankService bank = atm.getBank();

        if (amount <= 0 || amount % 100 != 0) {
            atm.getScreen().show("Enter a multiple of 100");
            return;
        }
        if (bank.getBalance(account) < amount) {
            atm.getScreen().show("Insufficient funds");
            return;
        }
        if (!atm.getDispenser().canDispense(amount)) {
            atm.getScreen().show("Machine cannot dispense this amount");
            return;
        }

        // Debit first. If the bank fails, we never touch the cash.
        if (!bank.debit(account, amount)) {
            atm.getScreen().show("Transaction declined");
            return;
        }

        atm.setState(new DispensingState());
        atm.getDispenser().dispense(amount);
        atm.getScreen().show("Please collect your cash");
        atm.releaseCard();
        atm.setState(new IdleState());
    }

    @Override
    public void ejectCard(ATM atm) {
        atm.releaseCard();
        atm.setState(new IdleState());
    }
}

Why the two cheap checks run before the debit:

• canDispense confirms the physical notes exist, so I never debit an account only to find I cannot make the amount.
• The debit is the point of no return, so everything that can fail cheaply happens before it.

The ATM itself is thin. It forwards every call to the current state. No business logic lives here, which is exactly what I want.

public class ATM {
    private ATMState state = new IdleState();
    private Card currentCard;
    private final CashDispenser dispenser;
    private final BankService bank;
    private final Screen screen;

    public ATM(CashDispenser dispenser, BankService bank, Screen screen) {
        this.dispenser = dispenser;
        this.bank = bank;
        this.screen = screen;
    }

    public void insertCard(Card card)       { state.insertCard(this, card); }
    public void enterPin(String pin)         { state.enterPin(this, pin); }
    public void selectWithdraw(double amt)   { state.selectWithdraw(this, amt); }
    public void ejectCard()                  { state.ejectCard(this); }

    public void setState(ATMState s) { this.state = s; }
    // getters/setters for card, dispenser, bank, screen...
}

Finally the dispenser, which owns the note math. Greedy pass over denominations sorted high to low, computed into a temporary plan first, committed only if the plan fully covers the amount.

• Greedy can fail (asking for 30 when you only have 20s), so I never half-dispense.
• Separating plan from commit makes canDispense and dispense share one honest source of truth instead of drifting apart.

public class CashDispenser {
    private final TreeMap<Integer, Integer> notes; // denom -> count, descending

    public CashDispenser(TreeMap<Integer, Integer> notes) {
        this.notes = notes; // use a descending comparator when building
    }

    public boolean canDispense(double amount) {
        return plan((int) amount) != null;
    }

    public Map<Integer, Integer> dispense(double amount) {
        Map<Integer, Integer> plan = plan((int) amount);
        if (plan == null) throw new IllegalStateException("Cannot dispense");
        plan.forEach((denom, count) -> notes.merge(denom, -count, Integer::sum));
        return plan;
    }

    private Map<Integer, Integer> plan(int amount) {
        Map<Integer, Integer> result = new HashMap<>();
        int remaining = amount;
        for (Map.Entry<Integer, Integer> e : notes.entrySet()) {
            int denom = e.getKey();
            int take = Math.min(remaining / denom, e.getValue());
            if (take > 0) {
                result.put(denom, take);
                remaining -= take * denom;
            }
        }
        return remaining == 0 ? result : null; // null means impossible
    }
}

One honest caveat I volunteer:

• Greedy is correct for canonical note sets (like 100, 200, 500, 2000) but not for every arbitrary set.
• If the interviewer pushes on exact-change with a weird denomination set, the clean fix is a small dynamic programming pass bounded by note counts.
• I would swap only plan(), since the rest of the class does not care how the plan was built.

5Design decisions and patterns used#

State pattern is the backbone.

• The machine's allowed actions change completely by screen, so each screen gets its own class.
• This kills the giant switch (currentScreen) that these designs usually rot into, and makes the valid transitions self-documenting.
• Asked "what happens if someone tries to withdraw before entering a PIN," I point at IdleState and HasCardState: the method simply is not implemented there, so it throws.
• The compiler and the structure enforce the rules, not my memory.

Strategy shows up in BankService and transaction types.

• BankService is an interface so the real network client and a test stub are interchangeable.
• If I needed different withdrawal rules per account type (a daily limit on checking, none on a business line), I would make WithdrawStrategy implementations rather than branching inside the state.

Factory is a light touch.

• A StateFactory or TransactionFactory keeps construction out of the states.
• I mention it but do not over-engineer: four new SomeState() calls do not justify a factory on their own.

Observer is my follow-up answer for receipts and audit logging.

• When a transaction completes, notify a ReceiptPrinter and an AuditLog without the state knowing about either.
• The state fires one event; who listens is somebody else's problem.

The bigger principle: the ATM class holds no logic. It is a context that delegates. That separation is what the interviewer is grading, more than any single pattern name.

The State pattern is not the answer because it is a pattern. It is the answer because it makes illegal transitions impossible to write.

6Handling edge cases and concurrency#

This problem is really a list of failure cases, so I treat it like one. This section is where Medium candidates separate from strong ones.

Debit succeeds but dispense fails (the scary one).

• I debited the account, then the dispenser jams.
• My ordering debits first because the bank is the source of truth and far more reliable than hardware.
• On a physical dispense failure I need a compensating credit back to the account and I flag the machine out of service.
• In the interview: wrap the dispense in a try/catch, on failure call bank.credit(account, amount) and move to an OutOfServiceState.
• Never leave the customer debited with no cash.

Wrong PIN.

• Counted per session, card retained after three.
• The counter lives in HasCardState, so a fresh insert starts fresh.
• I would not store the lifetime count locally: the bank owns lockout policy, because the real limit spans all ATMs, not just this one.

The machine runs out of a denomination.

• Handled by plan() returning null.
• If I cannot make the exact amount from available notes, I decline before debiting.
• That is why canDispense runs before the bank call.

Card yanked out mid-transaction, or a timeout.

• Each state should honor a timeout that ejects the card and resets to idle.
• I model it as the state scheduling a reset that fires if no input arrives, say after 30 seconds of silence.

Concurrency, the honest answer:

• A single physical ATM serves one customer at a time, so there is no concurrency inside the machine.
• The one shared resource is the account balance, and that race lives at the bank, not here.
• So I do not sprinkle locks around the ATM. Instead I make the bank debit atomic and idempotent.
• I attach a transaction ID to each withdrawal so a retry after a timeout cannot double-debit.
• If the interviewer insists on thread safety for a simulator, I guard the dispenser's note map, since the inventory is the one piece of mutable shared state.

7Extensions and follow-ups#

• Receipts and audit: wire in the Observer I mentioned. Each completed Transaction fans out to printer and log.
• Deposits with note counting: add a DepositState and a cash acceptor that validates and tallies inserted notes before crediting.
• Multiple accounts per card: after auth, add an AccountSelectionState.
• Admin mode: a separate state tree for refilling cash and running diagnostics, entered with a service key, not a customer card.
• Network partition: if BankService is unreachable, fail into OutOfServiceState rather than guessing. Offline withdrawal is a business decision, not an engineering default.

8What the interviewer is really checking#

• They want to see you recognized the State pattern without being told, because the ordered flow is the entire problem.
• They want the withdraw sequence correct: funds check, cash check, debit, then dispense, with no path that dispenses before debiting.
• They watch whether you keep the bank at arm's length behind an interface instead of pretending the ATM owns balances.
• They want to hear the failure story: debit-then-jam, and how you compensate.
• If you reach for locks everywhere, that is a small red flag. The better answer is idempotent debits and a single-session machine.
• Scope discipline counts too. The candidates who try to build the whole bank run out of time and never get to the part that actually matters.

If you liked the state machine here, try Design a Vending Machine next, and read up on the State and Strategy patterns side by side.