How to design a Vending Machine

Functional Requirement

1. Ability to select an item
2. Ability to pay for an item (cash/credit card payments)
3. Dispense the item
4. Notify the owner about inventory status

Non-functional Requirement

1. Products and prices should be clearly shown
2. After pressing the button, the machine should dispense products instantly
3. When a product falls, the product shouldn’t be stuck
4. The change returned to customers should be accurate

High Level Design

Typically a vending machine works in State Pattern, which mainly includes three states: Ready, Payment and Dispensing.
Once a customer chooses a product, the machine changes from the Ready state to the Payment state. If the payment is successful, it changes into the Dispensing state, otherwise, it rolls back to the Ready state and waits for the next purchase.

For the internal mechanism, once a customer chooses an item, the item selection module will be triggered and sends messages to the Payment module which includes the item price. In the Payment system, it will calculate the money paid and the change. If there is not enough change to dispense, the machine should return all money entered by the customer and shouldn’t dispense the item.

Key Implementation Challenges

1. Hardware Abstraction Layer(HAL)
   If the type of the internal coin machine is changed, do we need to re-write the code? Not necessarily, we can use the Hardware Abstraction Layer(HAL) to abstract the hardware details, so that the code logic of the coin machine can be reused. By introducing interfaces, we can isolate the hardware details from the upper layer business logic.

2. The Coin Change Algorithm
   For the coin change algorithm, we can use the greedy algorithm to dispense the change with the least number of coins. Otherwise, we can use the dynamic programming to find the optimal solution.

3. Atomicity & Error Handling
   Case1: The customer inputs coins -> the machine dispenses the item -> the item is not dispensed -> the machine diesn’t return the coins
   Case2: the machine is dispensing the item -> the power is cut off

To avoid the above cases, we can introduce concepts like the Transaction in database to ensure the atomicity of the operation.
Two-phase commit:

1. Check the hardware status (whether the electric motor is working? whether the inventory is enough?)
2. Deduce the inventory and the customer balance
3. Command the hardware to dispense the item
4. The sensor checks the item is dispensed successfully
5. Rollback: If step 3 fails, the return process will be triggered and the error log will be recorde

Deep Dive Questions

1. About Concurrency
   Question: If a customer presses the buttons of two different items at the same time, or enter a coin when the machine is dispensing, what will happen in the system?
   Answer: We can define a event queue to handle the concurrent requests, all the hardware interruptions and button presses should be regarded as events and be processes in the order of arrival.

2. About Power Failure Recovery
   Question: When the power is cut off when the machine is dispensing coins, what should happen after the power is restored?
   Answer: Uses NVRAM to record write-ahead log. Recording the log before execution and checking the log after the power is restored.