Requirements

Functional Requirements:

1. users should be able to have a product catalog
2. users should be able to add stores/create stores
3. users should be able to monitor their inventory
4. users should be able to manage orders through various stages - order placement, order tracking, order shipping
5. users should be able to set payment configurations - being able to accept using different types of cards, accounts, currencies etc.
6. merchants should be able to process refunds/accept returns of products.
7. users should be able to create and save carts and come back and be able to order them within a ttl.

Non-Functional Requirements:

1. the inventory management portion of the system should be consistent as eventual consistency could lead to same item being double ordered.
2. payment processing system should be available with idempotency so as to avoid duplicate transactions.
3. Avoid Cross tenant data leaks - a query for a given store should see data from that store or merchant and not across everyone.
4. the system should scale up to a million users - DAU - facilitating million orders per hour
5. any store data/user data should stay secure both at rest and in transit.
6. There should reside a backend fraud analytics system to capture any potential fraudulent merchants/orders

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

API Design - We will use REST API as it is simple for CRUD operations and provides atomicity - especially needed for inventories and transactions

1. POST- /addMerchant
   1. header: authorization/authentication token
   2. body: {'merchantName':string, 'merchantOnboardedTimestamp': timestamp,'merchantEmail':string, 'merchantPhone':varchar,'merchantCountry': countryName,'merchantLocation':location}
   3. return: boolean status
2. POST - /addStore
   1. header: authorization/authentication token
   2. body: {'merchantId':int, 'storeOnboardedTimestamp': timestamp, 'storePhone':varchar,'storeCountry': countryName,'storeLocation':location,storeType: string,storeName: string}
   3. return: boolean status
3. POST- /addProduct
   1. header: authorization/authentication token
   2. body: {'merchantName':string, 'storeName: string,productName: string, productBrand: string, productType: string, productCategory: string, productIndustry: string,productColor: string, productSize: varchar, productLanguage: string}
   3. return: boolean status
4. POST - /addItemToCart
   1. header: authorization/authentication token
   2. body: {'merchantName':string, 'storeName: string,productName: string, ,productColor: string, productSize: varchar, productLanguage: string}
   3. return: {'cartId':int,'cartItemCount':int}
5. Delete - /removeItemFromCart
   1. header: authorization/authentication token
   2. body: {'merchantName':string, 'storeName: string,productName: string, ,productColor: string, productSize: varchar, productLanguage: string, cartId: int}
   3. return: {'cartId':int,'cartItemCount':int}
6. POST - /createOrder
   1. header: authorization/authentication token
   2. body: {'cartId':int, orderTimestamp: timestamp, 'storeName': string}
   3. return: boolean status
7. POST - /createPaymentIntent
   1. header: authorization/authentication token
   2. body: {'transactionIntentId':int, transactionIntentTimestamp: timestamp, 'transactionAmount': float, 'paymentMethod':string}
   3. return: {transactionIntentToken: string}
8. POST - /createPayment
   1. header: authorization/authentication token - transactionIntentToken
   2. body: {'transactionIntentId':int, transactionTimestamp: timestamp, encrypted{bankAccountDetails or CreditCardDetails}}
   3. return: boolean status

High-Level Design

The service layer resides behind an api gateway which handles all the authentication and rate limiting/load balancing etc. All our databases to start of can be Postgres. Postgres is reasonably optimal for both write and read operations and as the system evolves if the reads/writes scale and we deem it to be sub optimal at that point we can shift to either DynamoDB or Cassandra.

1. The addMerchant service adds a new merchant that needs to be onboarded and updates the database after running validation checks.
2. The addStore service and addProduct service are used to add stores and products and update the database.
3. The addItemToCart adds any item to cart after checking the inventory. The inventory should be its own database isolated from the product/store/merchant database. We are still in the OLTP phase of the system and we also wanted to consider avoiding cross tenant leaks. This provides with that. Any time a client selects a product variety to the cart, this service checks the inventory table and updates the cart accordingly. When multiple users try to reach out to the same last remaining product at the same time (concurrent processes) - we can lock out an entire row of the inventory to prevent parallel item additions.
4. The removeItemToCart adds an item back to the inventory removing it from the cart.
5. Once the cart is finalized and ready to be ordered, the createOrder service creates an order with the potential transaction amount. The transactions/orders reside in their own Database.
6. The createPaymentIntent service creates a new payment intent to process the order transaction, and the createPayment service process the transaction interacting with the external payment system.

The cartId would be an idempotent key for the cart. The paymentIntentId would be an idempotent key for a transaction. The paymentIntent table which would capture each stage of the potential transaction will have its own idempotency key for each stage of the process. The inventory system comprises of a redis cache for frequently ordered items with a short TTL - may be an hour or so which could be configured to be lower during the festive or holiday season. This enables the system to respond fast to inventory items being present and Redis provides idempotency with its key value structure provides fast atomic coordination.

Database Design

1. products - productId, productName, productBrand, productType, productCategory, productIndustry, storeId, merchantId, productPrice
2. productVarieties: productVarietyId, productId, productName, productColor, productSize, productLanguage, storeId, merchantId
3. productInventory: productInventoryId, productId, productVarietyId, productCount, storeId, merchantId
4. stores - storeId, storeName, storeCountry, storeLocation, storeState, storeType, merchantId
5. carts - cartId, productsInCart
6. orders - orderId, cartId, orderTimeStamp, , orderPaymentMethodId, storeId
7. merchants - merchantId, merchantName, merchantEmail, merchantPhone, merchantLocation, merchantCountry
8. transactionIntent - transactionIntentId, orderId, paymentMethodId, transactionAmount, transactionStatus, storeId
9. transaction - transactionId, transactionIntentId, transactionAmount, storeId
10. paymentMethod, paymentMethodId, paymentType,

Detailed Component Design

1. Th