System requirements

Functional:

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

Users can choose the product and its number in the vending machine.

Users can pay for the product with a bank card, cash, Paypal, the cryptocurrency and get the choosen product.

If users choose a product number that isn't available, the vending machine shows an error.

If users choose the product and there is a blackout, the vending machine shows an error.

If users choose the product and there is an internet connection issue, the vending machine shows an error.

Non-Functional:

• Performance: The service should serve the users with minimal latency.
• Reliability: The service should be highly available and fault-tolerant.
• Scalability: Should scale dynamically based on user load.
• Security: Ensure secure processing of the user's payment transactions.
• Maintainability: Code and system architecture should be easy to maintain and extend.

Capacity estimation

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

Assumptions

1. Total Number of the vending machines: Assume the system needs to support 10 million vending machines.
2. Product Selection Frequency: On average, an active user selects a product in the vending machine once every 5 minutes.

Calculations

• Write Operations: Each user selects and buys a product in a vending machine every 5 minutes. For 10 million vending machines, that's (10,000,000 users×1 update)/5 minutes=2,000,000 buys/minutes

Resource Estimation

• Data Storage: Each product might need about 100 bytes (product ID, status, timestamp, name, price, count) and each vending machine needs 100 bytes contains(ID, status, timestamp, location) ,one vending machine may sell 100 products and it requires 10 Kbytes,

10 million vending machines need about 100 GBytes.

• Network Bandwidth: With frequent buying products and high concurrency, substantial bandwidth will be needed, especially for service synchronization across different regions if the service is globally distributed.
• Memory and CPU: To ensure real-time performance, a significant portion of operations should be handled in memory.
• High CPU resources will be required to process the continuous flow of reads and writes.

Considerations

• Database Choices: Given the midle write and read requirements, and the keeping the strong consistency, it needs to use SQL database like PostgresSQL, which can handle high throughput and horizontal scaling.
• Caching: Implementing caching mechanisms to reduce database load, using solutions like Redis to cache frequent queries or active user statuses.
• Load Balancers: To manage traffic and ensure even distribution of requests across servers.

API design

Define what APIs are expected from the system...

API Endpoints

1. Pay for the products selected by the user

2. Get the product list from the vending machine

Admin API:

1. Add a new vending machine:

1. Get the list of the vending machines:

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...

Below is a detailed schema using PostgresSQL.

Main Tables in PostgressSQL

VendingMachineProduct Table

• productId (Composite Partition Key): String that uniquely identifies a product.
• vendingMachineId (Composite Partition Key): String that uniquely identifies a vending machine
• status: String indicating the current status (e.g., "available", "none").
• title: String
• lastUpdated: Timestamp of the last product update.
• expDate: Timestamp expiration date
• price: Double price for one unit of a product
• amount: Int amount of the product
• This table serves as a list of the products loaded into the vending machines.

VendingMachine Table

• vendingMachineId (Partition Key): String
• name: String name of the vending machine.
• createdAt: Timestamp when it was created.
• longitude: String
• latitude: String

This table has information about the vending machines that are installed.

Order Table

• orderId (Partition Key): String
• vendingMachineId: String
• createdAt: Timestamp when it was created.
• productId: String
• totalPrice: Double
• status: String ("processed","error","pending")
• updatedAt: timestamp

This table has information about the vending machine orders.

OrderDetail Table

• orderId (Partition Key): String
• productId (Partition Key): String
• price: Double
• amount: Double

This table has information about the specific vending machine orders.

High-level design

Key Components

API Gateway

• Distributes incoming traffic and requests evenly across web servers.
• Enhances the system's reliability and availability.
• Secure the HTTP traffic by using HTTPS

Payment service

• Process the payments with a bank card or cash.
• Integrates with third-party payment services.
• Persists the payment tracking id that third-party services return after payment processing.

Order service

• Store the vending machine information about the products the users selected.
• Check if the product amount is available by calling the Product List service.
• Sends payment requests to the Payment service and manages the payment process.
• Perisists the product information that the users can select in a vending machine, before that, the Order service checks the product amount.

Product List service

• Supports the list of products that the users can select and pay.
• Controls the number of products and vending machines.
• Persists the information about products and the vending machines to Database (PostgresSQL)
• Caches the product information about the most frequently requested.

Request flows

We'll examine the scenario:

Selecting and paying for the product from the vending machine.

1. Selecting and paying for the product from the vending machine.

This flow describes what happens when a user selects the product.

Sequence of Events:

1. Client Request: A client application selects a number of products in the vending machine.
2. API Gateway: Distributes the request to one of the available Order service.
3. The Order service: Receives the request and starts the business transaction, and persists the information about it to the Database.
4. The client application can select the list of products.
5. When the client application finishes the business transaction, the Order service calls the Product List service to check product number availability. If all necessary products are presented, the Order service waits from the client application the payment request. Otherwise, the Order service sends the error message to the client application.
6. If the Payment service receives the payment request from Order service,it starts the payment process by contacting the third-party service like Stripe, before that, the Payment service persists the payment tracking Id, the current timestamp, and status.
7. The Order service waits for the Payment service send back the payment status.If a payment is successful, the Order service commit the transaction and returns success to the client application, otherwise it sends the error message.
8. The product List service cache: caches the the most frequently requested products.

Detailed component design

1. Web Server

Purpose: The Web Server handles all incoming API requests for updating and retrieving user statuses.

Key Responsibilities:

• Request Routing: Distributes incoming requests to appropriate handlers.
• Status Update Handling: Interacts with the Message Queue to manage asynchronous status updates.
• Status Retrieval: Queries the Cache Layer directly for status retrievals and updates the cache if necessary.

Scalability:

• Load Balancing: Utilizes a load balancer to distribute incoming traffic evenly across multiple instances, ensuring no single point of overload.
• Statelessness: Maintains no local state, allowing any request to be served by any instance, facilitating easy scaling.

Technologies:

• Language/Framework: Could use Node.js for its non-blocking I/O model, well-suited for handling a large number of simultaneous connections.
• Integration: Connects with Redis for caching and RabbitMQ for message queuing to handle high throughput and asynchronous processing.

2. Cache Layer

Purpose: The Cache Layer provides fast access to frequently accessed data, such as user statuses, to reduce latency and database load.

Key Responsibilities:

• Data Storage: Temporarily stores user statuses for quick retrieval.
• Cache Invalidation: Ensures that data in the cache is up-to-date with the latest changes from the database.

Scalability:

• Horizontal Scaling: Supports scaling out by adding more cache nodes. Data partitioning can be applied to distribute the load evenly across nodes.
• Consistency: Implements eventual consistency mechanisms to handle synchronization between cache nodes and the primary database.

Technologies:

• Redis: Ideal for this role due to its performance and features like publish/subscribe, which are useful for invalidating cache entries when data changes.

3. Notification Service

Purpose: Manages the distribution of real-time status updates to other clients and services.

Key Responsibilities:

• Message Processing: Processes messages from the Message Queue regarding status updates.
• Client Notification: Notifies relevant clients of status changes, using efficient communication protocols.

Scalability:

• Asynchronous Processing: Handles incoming messages asynchronously, allowing for high throughput without blocking.
• Scalable Distribution: Can scale horizontally by adding more instances as the number of notifications or the complexity of the routing logic increases.

Technologies:

• WebSocket: For real-time, bidirectional communication between clients and the server.
• RabbitMQ: Used for decoupling the receipt of status updates from their processing and distribution.

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

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

Future improvements

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