Requirements

Functional Requirements:

• Users can browse available products on a mobile app, select one, and complete a purchase.
• The system supports various payment methods including cash, coins. Online payment has to be made through mobile app
• The system tracks product stock levels in real time, updates inventory after each transaction, and generates alerts when stock falls below a minimum threshold.
• The system issues a refund for the payment amount if a transaction fails or the user cancels it.
• Operators can access the machine in a maintenance mode for restocking products, performing repairs, updating configuration, and viewing diagnostic information.

Non-Functional Requirements:

• List the key non-functional requirements (e.g: low latency, scalability, reliability, etc.)...

Use cases

1. User should be able to scan the QR code on the vending machine and open the catalog of the vending machine on his mobile browser
2. User should be able to browse product and it's prices from the catalog and add them to the cart
3. User should be able to search for the product from the interface and add them to the cart
4. User should be able to make payment for the cart and get his product from the machine. User should be able to make payment through an online QR on mobiel app or through cash on the vending machine
5. vending machine should be able to accept the cash from user only if it is able to tender exact change. If not, system should return user cash and decline the transaction
6. System should display the image of the product in the product catalog
7. System should track the inventory stock in the vending machine and generate alert to the admin when the stock goes below threshold
8. Authorized personnel should be able to scan the QR code on the vending machine, restock the vending machine and update the stock details through the mobile app
9. User should be able to raise complaint on an order and get back payment
10. Operators should be able to onboard product, its price and description in the product catalog

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

a) API Gateway: Acts as the front end for all the API services. Handles rate limiting and authentication through IAM. Forwards the request to either caching service, user details & history service, search service, product catalog service, inventory management service, cast service

URL: Root/api/v1/*

b) Search service API: Acts as an API for the users to search for products on the mobile app. Returns the relevant search items to the user mobile app. This API is trigerred by user mobile app

URL: GET: Root/api/v1/search?query={searchword}

c) Order service API: Acts as an API to create and fetch order. This API is trigerred by user mobile app

URL: GET: Root/api/v1/orders (or)

GET: Root /api/v1/orders?userId=U1&page=0&limit=10

URL: POST: Root/api/v1/orders

URL: GET: Root/api/v1/orders/{order_id}

d) User details service API: Acts as an API for the user to add or edit his details on the system. This API is trigerred by user mobile app

URL: GET: Root/api/v1/users

URL: PUT: Root/api/v1/users

e) Product Catalog service API: Acts as an API to display the product catalog to the user on his mobile app. This API is trigerred by user mobile app

URL: GET: Root/api/v1/productcatalog/

f) Inventory Management Service API: Acts as an API to update the inventory balance based on the transactions executed at the vending machine. This API is trigerred by the vendor machine

URL:PUT: Root/api/v1/im

g) Product Dispatch Service API: Acts as an API to the service the triggers request to vending machine to dispatch the product. This API is trigerred by the payment service. Returns dispatch status and details

URL:PUT: Root/api/v1/pds

h) Cart service API: Acts as an API to for the cart service.

URL:GET: Root/v1/cartservice

PUT: Root/v1/cartservice

POST: Root/v1/cartservice

Delete: Root/v1/cartservice

i) Payment service API: Acts as an API to handle payments. This API is trigerred by the order service. Returns payment status and transaction details

URL: POST: Root/v1/paymentservice

GET: Root/v1/paymentservice

j) Logging&Monitoring API: Acts as an API for the vending machine to send logs and machine diagnostics periodically. This API is for API gateway, from which the diagnostics

URL: POST:Root/v1/logNmontservice/machineID=abc

h) Notification service: API to send notification from the vending machine in case the inventory of a product falls below the threshold

URL: POST: Root/v1/notify/

High-Level Design

1. API Gateway: Used as a PaaS or SaaS service. Acts as the interface for the external requests (requests from mobile apps and vending machine). Includes request rate limiting and DDoS protection
2. IAM: Validates user and service authentication and authorization. Handles user roles and permissions. Hosted as a PaaS service or native cloud service like EntraID. Supports Oauth2.0, mTLS certificates and managed identity
3. Search service: Enables the user to search for a specific product. Returns available products as per each vending machine. Tightly coupled with elastic search DB for search function. Hosted on a container
4. Inventory Management Service: Responsible for monitoring the inventory of a product per machine. Will trigger automatic notification to admin in case the inventory of a product falls below a threshold
5. Product catalog service: Displays all the available products per machine in a sorted manner on the user mobile app based on the inventory avaialbility in the machine table of the Database
6. Cache service storage: Usually Redis or memcache service. Coupled with Product catalog service and search service to retrieve the cached content and display to users
7. User details & History service: handles user details (mobile number, email etc.,) and the history of orders placed by the user
8. Cart service: Allows user to add products to a checkout cart. Once cart service is checked out, order is created and subsequently payment requests are generated. Locks the product in the machine table in the DB the moment a product is added to the cart
9. Order service: Creates orders once the cart is checked and corresponding order details (order id etc.,) are generated and stored in DB. Forwards to payment service
10. Logging & Monitoring service: This is for the vending machines to send machine diagnostics, logs and status periodically to a central logging and monitoring solution. Machine sends the logs and diagnostics to a queuing service periodically and from there the logging & monitoring service will pick it up asynchronously
11. Logging service: Azure monitor logs or AWS cloud watch logs as a centralized location to store the log files of all the services in scope
12. Notification Service: Service which sends notification to the admin devices in case inventory of a product goes below the threshold
13. Elastic Search Update Service: Event consumer which consumes events from the secondary database to note changes to the product and machine table and update the same in the elasticsearchDB
14. Primary Database: PaaS based PostgreDB service for SQL based data storage. Indexed on
    1. Customer id in Orders table,
    2. Product id in machine table
    3. Order id in Complaints table
    4. Order id in Order items table

and partitioned on

a. Created date in orders table

b. Created date in conversations table for faster data retrieval

1. Secondary Database: Replica db for reads. Orders, payment, machine, order items are strongly consistent tables. Customer, compliants, conversations, product are eventually consistent tables in the DB

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

a) Database : 20 GB for primary and secondary database each, considering 100000 users annually with an average of 100 orders and 3 items per order and 300 vending machines and 5000 total products available in the catalogue, with SDD state storage, 4 CPU cores and 16GB RAM

b) IAM : Cloud native (Azure or AWS)

c) Load Balancer: Standard and cloud native. Scale up = >70% CPU for 10 min or memory > 75% for 10 min

Scale down = <40% CPU for 20 min or memory< 40% for 20 min

d) Event & Queuing_Broker: Standard tier (Azure service bus)

e) All the services will be container hosted with a RAM of 4 GB and CPU of 2 cores. These services will be behind a load balancer and a auto scaler

Network architecture:

1. Mobile app – Public network
2. API Gateway – Public IP and Subnet 1. Inbound all the https connections. Outbound is all the https connections
3. Loadbalancer – Private IP and subnet 2. Inbound from API Gateway IP. Outbound to API subnet 3,4,5, 6
4. Services (search, order, product catalog, cache, user details and history, cart) – Private IP and subnet 3. Inbound from Loadbalancer IP. Outbound to client devices over internet HTTPs and private endpoint of primary and replica DBs
5. Services (Payment) – Private IP and subnet 4. Inbound from Load balancer IP. Outbound to NAT gateway IP over HTTPs webhook protocols and private endpoint of primary and replica DBs
6. Services (Product dispatch) – Private IP and subnet 5. Inbound from Loadbalancer IP. Outbound to vending machine IPs over Internet https and private endpoint of primary and replica DBs
7. Azure Service bus (event and queuing system) is accessed by azure postgres DB by private endpoint
8. Service (elasticsearchupdate service) – Private IP and subnet 6 is accessed by Azure servicebus private endpoint
9. Azure elastic search (primary and replica) is accessed by elastic search update service by private endpoint

Authentication:

The below is my authentication design:

1.  Mobile app to api gateway: Oauth2.0+JWT
2.  Azure Api gateway to Azure IAM: Managed Identity
3. Azure API gateway /Load balancer to Backend services (order, cart, catalog, etc.,) hosted on azure containers: mTLS
4. Azure Backend services (order, cart, catalog etc.,) to databases (azure postgres): Managed identity (tokens included)
5. Primary DB to Replica DB: Not applicable and very internal to azure infra
6. Azure Backend services on container (order, cart, catalog etc.,)to Azure Cache (redis) : Manged identity (includes token based authentication)
7. Azure Backend services on container (DB events service, notification service etc.,) to azure service bus : Managed identity
8. Azure backend services to azure elastic search : Manged identity
9. Azure backend service on container (product dispatch service) to vending machine: mTLS
10. Azure backend service on container (payment service) to Payment gateway: Mutually agreed mTLS and Oauth2.0 as per payment standards.