System requirements

Functional:

• User could pay with multiple methods
• Credit/Debit card
• Cash
• User can select what they want to buy from vending machine
• There will be prices listed for each item
• Dynamic price changes and dynamic item changes

Non-Functional:

• Prioritize Consistency -> For example we dont want user to be able to pay for something out of stock
• Available but prioritizing consistency

Capacity estimation

100 purchases a day -> 365 000 purchases a year

We will keep history for last 1 year

Item Table:

itemID -> 4 bytes

Price -> 4 bytes

ItemName -> 21 bytes

ImageKey -> 4 bytes

Bytes per row: 33 bytes

Would not need to worry about capacity of item DB

Transaction Table:

TransactionID -> 4 bytes

itemID -> 4 bytes

Price -> 4 bytes

ItemName -> 21 bytes

Success -> 1 Bytes

Bytes per row: 34 bytes per row

365 000 * 34 = ~12.5MB per year

Would not need to worry about capacity of transaction DB

Do not need to worry about scaling horizontally for now

API design

External Endpoints:

GET:

• Get items and prices to display

POST:

• Pay transaction

Internal Endpoints:

POST:

• transaction

Database design

SQL DB -> MySQL

Transactions:

• TransactionID (VARCHAR)
• Price (FLOAT)
• ItemID (VARCHAR)
• Time of Transaction(DATETIME)
• Success (BOOLEAN)

Items:

• ItemID (VARCHAR)
• Price (FLOAT)
• ItemName (VARCHAR)
• ImageKey (VARCHAR)

High-level design

Vending machine display will not be changed much, we can assume that most requests will be requests to pay for a certain item

We will use Stripe third party API to handle credit/debit card, there should be some hardware in the front-end to calculate actual cash being used to pay

To display the items and the prices for the items, we will have a GET endpoint to grab each item

• Each item will contain item name, item price and item image
• Image will be stored in S3 bucket and can be cached in CDN (if necessary)

Request flows

To Display UI:

GET request to get items -> Client side logic to display items

Pay for item:

POST request to pay -> server side authenticates and approves payment through Stripe

Detailed component design

Transactions -> Transaction table includes itemID, time of transaction, price (include price separately in case item price changes), success

When user sends POST request to pay, we store the transaction in transaction table (will store both failed and successful transactions)

Can add extra layer of security -> If user fails 3 times then we will autofail -> Stripe probably has a response for if user is locked out for the day -> server side will use that response to display to client side

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

Too many people buying at once, will be write heavy

Future improvements

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