Getting Ready: Vending Machine

Vending machines are everywhere — airports, office lobbies, train stations, university corridors. The global vending machine market exceeds $25 billion, with over 15 million machines deployed worldwide. Companies like Coca-Cola, PepsiCo, and startups like Vendron build sophisticated software that manages inventory, accepts multiple payment types, handles partial refunds, and reports real-time telemetry to operators.

From an engineering perspective, a vending machine is a finite state machine brought to life in code. At any given moment, the machine is in exactly one state — idle and waiting, holding inserted money, dispensing a product, or out of stock. Each user action (insert coin, select product, request refund) triggers a transition to a different state. Not every action is valid in every state: you can't dispense a product before money is inserted, and you can't insert coins while the machine is already dispensing.

This is why the Vending Machine is one of the most frequently asked LLD interview questions at companies like Amazon, Google, Microsoft, and Goldman Sachs. It's the canonical showcase for the State Pattern — and interviewers use it to test whether a candidate truly understands state-driven design, or just memorized class diagrams.

Beyond the State Pattern, this problem introduces essential design skills: managing inventory with thread-safe operations, handling currency arithmetic (coin combinations and change calculation), and building an extensible payment system. It's a compact yet rich problem that rewards careful design.

By the end of this design problem, you will:

• Model a real-world system as a state machine — identify states, transitions, guards, and actions from plain-English requirements
• Apply the State Pattern to eliminate brittle if/else chains and make state transitions safe and extensible (Fundamentals S12)
• Use the Singleton Pattern to ensure exactly one vending machine instance manages shared inventory (Fundamentals S10)
• Draw a State Machine Diagram showing every valid transition and event trigger
• Draw a Class Diagram deriving each class, attribute, and relationship from requirements
• Implement the complete system in Python and Java with clean separation of concerns
• Test edge cases — insufficient funds, out-of-stock items, exact change scenarios, concurrent access

Before starting this problem, make sure you're comfortable with:

• OOP Fundamentals — classes, objects, encapsulation, and polymorphism (Fundamentals S2)
• OOP Relationships — especially Composition and Association; you'll use both to model parts of the machine (Fundamentals S4)
• State Pattern — how an object changes behavior when its internal state changes. This is the central pattern of the Vending Machine. If you're not confident with State, review Fundamentals S12 first.
• Singleton Pattern — ensuring a single instance of a class. We'll keep a single machine managing all inventory (Fundamentals S10).
• UML State Machine Diagrams — how to read states, transitions, guards, and events (Fundamentals S5)
• UML Class Diagrams — how to read classes, attributes, methods, and relationship arrows (Fundamentals S5)

You should also have completed at least one earlier design problem (e.g., DP1 Parking Lot or DP5 Logging Framework) so you're familiar with the requirements → UML → code → patterns workflow.

We will design: The core domain logic of a vending machine — its state management, product inventory, coin handling (insert, validate, return change), product selection and dispensing, and the class structure that ties it all together.

We will NOT design: Database persistence, REST APIs, hardware integration (motor control, coin validators), distributed inventory management across multiple machines, a user interface, or networking. This is a Low Level Design (object-oriented) exercise, not a System Design (infrastructure) problem.

Difficulty: Easy — This is an excellent early problem because the state machine is small (4-5 states) and the class count is manageable (6-8 classes). However, don't mistake "easy" for "shallow." The depth comes from correctly modeling state transitions, handling edge cases in payment arithmetic, and justifying every design choice.

Before designing the software, let's understand the physical system we're modeling:

1. Idle state — The machine displays available products and their prices. It waits for user interaction.
2. Coin insertion — The user inserts coins one at a time. The machine accumulates the total. A running balance is displayed.
3. Product selection — The user presses a button corresponding to a product. The machine checks: (a) is the product in stock? (b) has enough money been inserted?
4. Dispensing — If both checks pass, the machine releases the product from its slot. If the inserted amount exceeds the price, it returns change.
5. Change return — The machine calculates the difference and dispenses coins. If exact change isn't available, some machines refuse the transaction entirely.
6. Refund — At any point before dispensing, the user can press a "refund" button to get all inserted coins back.
7. Out of stock — When a product's inventory hits zero, the machine shows it as unavailable. If ALL products are out of stock, the machine enters a special state refusing all further transactions until restocked by an operator.

Notice that these steps naturally map to states and transitions — which is exactly what we'll formalize in our design.