System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

1. Product Selection:
   • Users should be able to view all available products in the UI.
   • Users should be able to select one or more products from the interface.
2. Payment Processing:
   • The system should support multiple payment methods (e.g., cash, credit/debit cards, mobile payments).
   • Upon product selection, the system must prompt the user for payment.
   • The system should securely process payments and provide confirmation after transaction completion.
3. Inventory Management:
   • The system should track product availability in real-time.
   • Users should be notified if a selected product is out of stock.
4. User Interaction:
   • The interface should be user-friendly and intuitive.
   • The system should provide clear instructions and feedback (e.g., "Please insert cash," "Select a payment method," etc.).
5. Refund Mechanism:
   • The system should have the capability to process refunds in case of errors or cancellations.
6. Admin Management:
   • Admin should be able to manage inventory (add/remove products) and view sales reports.

Non-Functional:

List non-functional requirements for the system...

1. Performance:
   • The system should process transactions within 3 seconds.
2. Security:
   • The system must ensure secure transactions and protect user data.
   • Sessions should be managed securely to prevent unauthorized access.
3. Scalability:
   • The system should be designed to easily add products and payment methods in the future.
4. Reliability:
   • The system should be operational 24/7 with minimal downtime.
5. Compliance:
   • The system must comply with regulations related to payment processing and data protection.

Capacity estimation

Estimate the scale of the system you are going to design...

This vending machine system will handle a single machine.

Assuming it holds around 30 products and every product has a stock of 10 units (restock daily). So it has around 400 items in its stock.

Assuming it can handle 100 transactions per day.

During peak time, it handles around 5 transactions per minute.

API design

Define what APIs are expected from the system...

GET /items

Response: a list of items object

Item:

id: String, display_name: String, price: String (for accurate number), stock: int

POST /makePayment

request: itemId: String, payment_method: enum, amount: String

Response: status (enum).

POST /dispenseItem

request: itemId: String

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

The only database tables we need here would probably be the inventory table and transaction history.

Inventory

item_id PK, Varchar

item_display_name Varchar

item_price Varchar

item_count INT

Transactions

transaction_id PK, Varchar

item_id FK, Varchar

status Varchar (inProgress, succeeded, failed)

started_at INT

completed_at INT

paymentMethod Varchar

cardNumber Varchar

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

There are four high level components in the system:

UI: This is the component where user interacts with the system. It provides a way for user to select the product, make payment, etc.

Transaction Processing Unit: This is the main orchestration unit, it fetches information from database, serves requests from UI, and forward payment information to gateway.

Database: This database contains the two tables listed above.

Payment Gateway: The Payment Gateway is a gateway to the outside payment system.

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

The whole flow can be modeled as several states. Ready, payments, dispense_item, dispense_charge, refund. The details are included in the state diagram.

When the user attempts to purchase an item, the following flow happened:

• Ready State
  • The system is in ready state, the UI should have query the GET /items API and displays the items and their inventory, price information.
  • The customer selects an item. The UI will query the inventory again.
    • If the item is out of stock, do not move to any state, shows an error message to the customer, move back to 1.
    • Otherwise, move to Payments state.
• Payment State
  • The system prompts the user for payment.
    • If the user does not attempt to pay within a timeframe, payment failed and move the system back to ready state.
  • Once payment is received, the UI calls POST /makePayment endpoint and the transaction processing unit either processes the payment if it is cash, or calls payment gateway to process it if it is credit / debit card.
    • The System should move to dispense_charge state if it's needed.
    • If payment is failed, move to ready stage.
    • Otherwise, moves the system to dispense_item state.
• Dispense Charge state
  • If charge is required, the system should dispense charge.
  • After that is done, move to dispense_item stage.
• Dispense Item state:
  • The system should dispense the item
    • If succeeded, move to ready state.
    • If failed, move to refund state.
• Refund state:
  • Refund the payment, and the move to ready stage

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

1. The payment gateway should interface with the user's credit / debit card bank, and have them process the payment in the system's stead. It needs to handle a few security concerns.
   1. Encryption of data, for privacy protection
   2. Certificate verification of the other party.
2. UI: the UI of a vending machine should be designed in a way that's easy to understand and handle. For example, when it is time to process payment, some light can highlight the card inserting or cash inserting machine. Every product should be listed and have its inventory information and price information shown clearly. Besides, when dealing with cards, it would be great if the UI will ask the customer to get the card first before dispensing the item.

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

The system chooses to use a outside payment gateway instead of implement a payment handling by itself, is a way of delegating the complicated payment handling logic, as well as leveraging the existing security and risk management features of the outside payment systems.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

The failure scenarios has been discussed in the high-level design.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?

In the future, the system can add a notification component, when the inventory is low, it can send a notification to ask people to refill its inventory.