Design a Vending Machine (LLD)

30-second answer

A state machine in disguise: four states and a table that gives every event one outcome in each. Money is integer cents, held in escrow until the drop sensor confirms.

Functional

Slots with a product, a price and a count
Accept coins (notes and cards as extensions)
Select, dispense, return change
Cancel and refund before dispensing
Sold-out slots and an out-of-service mode
Admin restock and coin refill

Non-functional

Never dispense without full payment
Never lose money: every coin is kept for a sale or returned
Exactly one outcome per event in each state
New payment methods need no state-logic edits
Deterministic tests (no clock or randomness in the core)

Out of scope

Coin validator hardware
A fleet of machines (an HLD follow-up)
Dynamic pricing (a follow-up)

A low-level design (LLD) question with two tests: spot the state machine fast, and handle money exactly.

New to this? Read State machines and observers first.

Clarifying questions and interface

Event	Accepted in	Outcome
`coin` (100, 25, 10, 5)	Idle, HasMoney	Into escrow; elsewhere it drops to the cup
`select(code)`	HasMoney	Dispense, SOLD OUT, "insert 15¢ more", or refund if no change
`cancel`	HasMoney	Refund the escrowed coins
`dropped`, `dropFailed`	Dispensing	Drop sensor: commit, or refund
`service`	Idle, HasMoney, OutOfService	Toggle out of service (refunds credit first)
`restock(code, n)`, `refill(coins)`	Idle, OutOfService	Admin: never mid-purchase
events `transition`, `sale`, `returned`, `rejected`		For display, telemetry and persistence

State transition table

Thirty-two cells, one outcome each. ✕ means rejected: nothing changes.

Event	Idle	HasMoney	Dispensing	OutOfService
coin	escrow → HasMoney	escrow, stay	✕	✕
select	✕ insert money first	sale → Dispensing¹	✕	✕
cancel	✕	refund → Idle	✕ too late	✕
dropped	✕	✕	commit → Idle	✕
dropFailed	✕	✕	refund → Idle	✕
service	→ OutOfService	refund → OutOfService	✕	→ Idle
restock	apply	✕	✕	apply
refill	apply	✕	✕	apply

Build the design in stages

Step through: the machine, then state objects instead of flags, then change-making and payment. Green marks what the latest stage added.

VendingMachine owns its inventory and coin box and points at its current state. Each state object (Idle, HasMoney, Dispensing, OutOfService) lists the events it accepts; HasMoney asks ChangeMaker for change before it sells. Payment methods share one interface, and telemetry observes the machine unseen.

◆ composition (owns)
◇ aggregation
△ inheritance / implements (dashed)
→ association · ⇢ dependency

Watch it run, and one purchase

Insert coins and press a slot.

How to approach it

Clarify
Payment, change, sensor, fleet.
Name the states and events
Four states, eight events.
Fill in the table
Unlisted means rejected.
Get the money right
Cents, escrow, real coins.
Walk a purchase, then break it
Sold out, no change, a jam.

The State pattern as a table

Each state maps the events it accepts to the next state. Anything else is rejected.

hasMoney: {
  select: (m, { code }) => {
    const slot = m.inventory.get(code);
    if (slot.soldOut) return no(`${code} is sold out`);
    const credit = sum(m.escrow);
    if (credit < slot.price) return no(`Insert ${slot.price - credit}¢ more`);
    const change = makeChange(credit - slot.price, m.box.with(m.escrow));
    if (!change) { m.refund('exact change only'); return 'idle'; }
    m.pending = { code, price: slot.price, change };
    return 'dispensing';
  },

Every rejection comes before any change, so nothing half-applies.

Money is integer cents
0.1 + 0.2 is 0.30000000000000004. A cola costs 65, not 0.65.
Escrow, then commit
Coins sit in escrow. dropped moves them into the tubes, pays the change and takes one item off the slot, once. Cancel and dropFailed return the same coins.

Making change

Greedy (biggest coin first) fails when coins run low. Owe 30¢ from one 25¢ and three 10¢: greedy takes the 25¢, then needs a missing 5¢. A bounded DP over the real counts finds 10 + 10 + 10:

for (const d of denoms) {                     // best[a]: fewest coins for amount a
  for (let a = 0; a <= amount; a++)
    for (let j = 0; j <= counts[d] && j * d <= a; j++)
      if (best[a - j * d] + j < next[a]) { next[a] = best[a - j * d] + j; pick[a] = j; }
}

Include the escrow: the customer's own quarter can be their change.

No change, no sale
DP returns null? Refuse, refund, back to Idle.
One event at a time
send() runs events in order, so none sees half-updated state.
Payment methods as a strategy
PaymentMethod has credit(), commit(price) and refund(). A card authorizes at select, captures on dropped, voids otherwise. The table doesn't change.
Tests
Loop over all 32 pairs. Add the greedy counterexample, the no-change refund and the failed drop.

Implementation

The same design in JavaScript, Java or Python. Java and Python add real locks.

Read more · 66 words

makeChange gets the tubes plus the inserted coins.
CoinBox.remove checks every coin first, so a payout can't half-happen.
The test walks all 32 pairs: 13 accepted, 19 must change nothing.

Code it yourself

Try the Vending Machine exercise: it checks every cell of your state table.

Telemetry for a fleet

Only if asked. Each machine uploads its events, and seq makes a re-sent batch safe.

// Money is integer cents everywhere: 0.1 + 0.2 is 0.30000000000000004 in floating point,
// and a cash box has to balance to the cent.
export const COINS = Object.freeze([100, 25, 10, 5]);                // accepted coins, largest first
export const sum = coins => coins.reduce((total, c) => total + c, 0);

export class Slot {
  constructor(code, product, price, count, capacity = 10) {
    Object.assign(this, { code, product, price, count, capacity });
  }
  get soldOut() { return this.count === 0; }                         // a property of one slot, not a machine state
}

export class Inventory {
  constructor(slots) { this.slots = new Map(slots.map(s => [s.code, s])); }
  get(code) { return this.slots.get(code); }
  take(code) {
    const slot = this.slots.get(code);
    if (!slot || slot.soldOut) throw new Error(`Nothing left in ${code}`);
    slot.count--;
  }
  restock(code, n) {
    const slot = this.slots.get(code);
    slot.count = Math.min(slot.capacity, slot.count + n);
  }
}

export class CoinBox {                                                // the change tubes
  constructor(counts = {}) { this.counts = Object.fromEntries(COINS.map(c => [c, counts[c] ?? 0])); }
  add(coins) { for (const c of coins) this.counts[c]++; }
  remove(coins) {
    const need = {};
    for (const c of coins) need[c] = (need[c] ?? 0) + 1;
    for (const c in need) if (this.counts[c] < need[c]) throw new Error(`Only ${this.counts[c]} × ${c}¢ left`);
    for (const c of coins) this.counts[c]--;                          // all or nothing
  }
  with(coins) {                                                       // counts as if `coins` were added
    const counts = { ...this.counts };
    for (const c of coins) counts[c]++;
    return counts;
  }
  total() { return COINS.reduce((t, c) => t + c * this.counts[c], 0); }
}

CREATE TABLE vend_events (
  machine_id text        NOT NULL,
  seq        bigint      NOT NULL,          -- per machine: re-sent batches are idempotent
  at         timestamptz NOT NULL,
  type       text        NOT NULL,          -- 'sale', 'refund', 'rejected', 'jam', 'restock'
  slot       text,
  amount     int,                           -- cents, never a float
  PRIMARY KEY (machine_id, seq)
);

Failure modes and trade-offs

What breaks	Effect	Mitigation
Item stuck	Paid, got nothing	No drop in 2 s: retry once, then refund and flag the slot
Power cut mid-purchase	Lost credit or double vend	Save every transition; refund on boot unless a drop was logged
Coin jams	Coins swallowed	Credit only after the validator confirms
Fake coin	Free products	Validator checks size and weight; unknown coins drop to the cup
Tubes run low	Can't pay change	DP check, refuse and refund; low-coins alert
Two buttons at once	Double vend	One event queue; Dispensing rejects select

Choice	Pros	Cons
Table vs `switch`	Every cell visible	More structure
Bounded DP vs greedy	Finds change when it exists	More code
Escrow vs a credit number	Exact refunds	Tracks coins
Same coins vs equal value	No change-making on refund	Needs an escrow tray

Follow-up questions

How would you add card payments?

A CardPayment behind PaymentMethod: authorize on select, capture on dropped, void otherwise.

How would you run a fleet of 10,000 machines?

Machines work offline and upload event logs numbered per machine, so re-sends are safe. The centre plans restocks and pushes prices, applied only when Idle.

How would you support dynamic pricing?

A PricingStrategy fed by config. Lock the price into pending at select so it can't change mid-purchase.

How would you add a buy-2 combo?

Make pending a basket. Each dropped commits one item. A failed item refunds its share.

How do you test it?

Table tests over all 32 pairs, plus long random runs that check the money adds up. Nothing random in the core, so failures repeat.

Check yourself

Question 1 of 3

Score 2 out of 3 or better to mark this page complete.

1. The tubes hold one 25¢ and three 10¢ coins, and no 5¢. The customer is owed 30¢. What does greedy change-making do?Pays 25¢ + 5¢Takes the 25¢, then can't pay the last 5¢, so it failsPays 10¢ + 10¢ + 10¢

Patterns behind this

The coding patterns this design is built on. Practise them and the design questions get easier.

Trade-offs

Bring it up before they ask

Functional

Non-functional

Out of scope

Clarifying questions and interface

State transition table

Build the design in stages

Watch it run, and one purchase

Vending machine state machine

How to approach it

Clarify

Name the states and events

Fill in the table

Get the money right

Walk a purchase, then break it

Events first

States

The State pattern as a table

Money is integer cents

Escrow, then commit

Making change

No change, no sale

One event at a time

Payment methods as a strategy

Tests

Implementation

Failure modes and trade-offs

Follow-up questions

Check yourself

Patterns behind this

Questions